JavaScript Code Style and Code Review

Stay organized with collections Save and categorize content based on your preferences.

Style expectations when writing code for Marketing as well as code review process.

Google Engineers adhere to rather strict rules about code style. To the best we can,Marketing tries to adhere to the same standards set company wide.

Style guides

Javascript is expected to follow the Google JavaScript style guide. Please̦ also read the AngularJS style guide. AngularJS code shown externally differs significantly from the way AngularJS code is written internally.

Linter

Linters inform you if your code is following at least some of the Google style expectations. It is expected that you would fix all lint errors before beginning the code review process.

Editor linters

Sublime and Webstorm support linting right in the editor so you may want to install one of these plugins.

Webstorm

  1. First install the Closure linter itself.

  2. Create a closure-linter-config.txt file somewhere in your home directory with the Closure linter configuration: --strict --jsdoc --summary --beep

  3. Go to Webstorm > Preferences and search for Closure Linter.

  4. Choose enable and provide the path of the closure linter. On mac, this might be something like: /usr/local/bin/gjslint

  5. Provide the path to the closure-linter-config.txt file you created.

Command line

There is a command line linter utility available. Download and run gjslint on the command line.

gjslint --check_html --strict --jslint_error=all --closurized_namespaces=goog,jfk,xxx,yyy -r path/to/files

You can also auto fix these errors with fixjsstyle (with the same flags).

Goro linter

If you're using goro, you can review lint errors there. Just go to the list view of your branch and notice the red or green boxes that appear next to your JavaScript files.

Code Review

Read Code reviews at Google for a general overview on the code review process. Before beginning your JavaScript code review, be sure to fix all lint errors.

Readability review

If you do not have Javscript readability, your cl will require approval by someone with readability. This is enforced if you're submitting code to google3. However, code submitted to git on borg does not have these automated processes.

The primary focus of a readability review is to check for adherence to our style guides. However, it may also include comments around design, scalability, localization, and performance.

Check out the Code review checklist checklist before beginning your JavaScript review, especially if this is your first time.

If your project contains a lot of JavaScript code (more than 1000 lines), it's strongly recommended that you begin code reviews early and do them in an iterative manner. Your reviewers are expected to just review the code that is changed or new, rather than existing code you already wrote. So it is extremely beneficial to begin the code review process early.

For larger code reviews, expect your review to take a few weeks.

Security review

At the bare minimum, it's expected that you would run an inquisition scan on your project prior to launch to catch low hanging security flaws such as outdated libraries and XSS attacks. Most projects do not require a formal security review beyond that.

Scenarios that might warrant a security review:

  • large, complex JavaScript
  • deals with PII
  • reads/manipulates query parameters
  • retrieves data from an outside source or api and displays it on the page

Discuss with your TPM if a security review is appropriate and to determine next steps for beginning a review.