Development: Code Style & Review
Two important aspects in developing good software worth extra mention is Code Styling and the process of Code Review.
Code Styling
This involves a number of techniques including:
- writing good comments, having them before each class, class variables, methods/functions and throughout your code
- variable naming conventions - the most important is to be consistent. If you have variables like firstName then you should not have last_name but, instead lastName (p.s. this style is called lowerCamelCase).
- consistent filenames
- meaningful names uses for variables, classes, methods/functions and any other resources
- keep code readable, use consistent indentations
- break up "large" blocks of code through modularization (creating other methods/function
Inside Industry
Inside Industry
....Antoine Pickard, Google Software Engineer
"Code styling is important when you have multiple developers sharing the same code. The Google style guides (publicly available) are a good starting point. You don't have to take Google's recommendations but you should establish a standard to cover the things that it covers. "
Example Google Style Guides
Code Review
After you've added files and made updates to existing code, it's time to merge that code into your Bitbucket Cloud repository. Before you merge, you want to ensure that you maintain code quality and won't break already existing features. To get the feedback you need for code updates and improvements, you can create a pull request that includes all lines of code you've added. Pull requests provide you with a method for requesting code reviews from your teammates and checking build status based on your most recent commit.
Option 1: Informal Code Review - "manually"
<<< ULearn option
This is the easiest option, and for many small teams and small companies this may be how they do code review. This means that you identify one (maybe more) co-developer's who know enough about the code you are working on to go over it with you. This may be done face-to-face or in google drive documents or even email. There is no standard way to achieve informal code review. While it is not documented in the same way as option 2 &3 it is certainly fast.
Option 2: Git remote repository Pull Requests
To use pull requests, you'll need to start with a branch or fork so that you can develop your code on a line separate from the main code base. You can see how pull requests fits into a larger workflow example on the Workflow for Git Feature Branching page.
STEP 1: assumes that the developer has his own branch or fork
STEP 2: Creating a Pull request
When you use branches or forked repositories to work on a separate line of code from the codebase, you can use pull requests to get your code reviewed and merge your changes from Bitbucket Cloud. When you're ready to start a discussion about your code changes, it's time to create a pull request. Before creating a pull request, you might want to compare your code changes to the destination repository.
Some suggestions for making pull requests more effective
STEP 3: The Co-Developer reviews your Pull (containing your Change List -CL)
Option 3: Internal Company Tools or Add on Extensions to SW Versioning systems
Some companies have their own Code Review tools that store the code review comments and allow for ease of distribution of review submissions. Also, some software versioning systems like github and bitbucket have their own methods to handle code review
Bitbucket tool
Github tool
