Skip to content

Instantly share code, notes, and snippets.

@roman-rr

roman-rr/experttrialproject.md

Last active November 28, 2019 23:51
Show Gist options
  • Save roman-rr/e5df994a8b2439b81fbc054e9d96dc45 to your computer and use it in GitHub Desktop.
Save roman-rr/e5df994a8b2439b81fbc054e9d96dc45 to your computer and use it in GitHub Desktop.
Download ZIP
JavaScript Expert Code Review
Raw
experttrialproject.md

Review Mastered: Roman Antonov

List sorted: Best -> Worst

Sohel-rana (gist)

Good readable code, but can write better if know new standarts.

Good practice (10)

  • Start all comments with a space make it easier to read.
  • Place 1 space before the leading brace.
  • Place 1 space before the opening parenthesis in control statements.
  • Do not padding blocks with blank lines.
  • Descriptive with naming.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.
  • Using soft tabs with 2 spaces.
  • Using JSDoc comments allow to generate docs
  • Use single quotes '' for strings.

Bad practice (9)

  • Using var can give reassign bugs. Should use let and const.
  • Using // for multi-line comments, instead of /** ... */.
  • Use named function expressions instead of function declarations. disallowFunctionDeclarations
  • Use default parameter syntax rather than mutating function arguments.
  • Functions with multiline signatures, should be indented: with each item on a line by itself, with a trailing comma on the last item.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Must have additional trailing comma at the args to cleaner git diffs.
  • Line-break on first line

Technical examples

  • Additional trailing comma example const hero = { firstName: 'Florence', lastName: 'Nightingale', };
Score: 4

Waleed Adel (gist)

Most modern code style

Good practice (8)

  • Using let instead of var.
  • Use single quotes '' for strings.
  • Start all comments with a space make it easier to read.
  • Place 1 space before the leading brace.
  • Place 1 space before the opening parenthesis in control statements.
  • Descriptive with naming.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.

Bad practice (10)

  • Using // for multi-line comments, instead of /** ... */.
  • Using hard tabs (space character) set to 4-8 spaces, instead of 2 spaces.
  • Use named function expressions instead of function declarations. disallowFunctionDeclarations
  • Use default parameter syntax rather than mutating function arguments.
  • Functions with multiline signatures, should be indented: with each item on a line by itself, with a trailing comma on the last item.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Must have additional trailing comma at the args to cleaner git diffs.
  • Do not pad your blocks with blank lines.

Technical examples

  • Function expressions syntax const short = function longUniqueMoreDescriptiveLexicalFoo() { ... };
Score: 3

Alexey Shmatov (gist)

Good redability, but oldest standarts

Good practice (7)

  • Start all comments with a space make it easier to read.
  • Place 1 space before the leading brace.
  • Place 1 space before the opening parenthesis in control statements.
  • Do not padding blocks with blank lines.
  • Descriptive with naming.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.

Bad practice (10)

  • Using var can give reassign bugs. Should use let and const.
  • Using // for multi-line comments, instead of /** ... */.
  • Using hard tabs (space character) set to 4 spaces, instead of 2 spaces.
  • Use single quotes '' for strings.
  • Use named function expressions instead of function declarations. disallowFunctionDeclarations
  • Use default parameter syntax rather than mutating function arguments.
  • Functions with multiline signatures, should be indented: with each item on a line by itself, with a trailing comma on the last item.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Must have additional trailing comma at the args to cleaner git diffs.

Technical examples

  • Default parameter syntax function handleThings(opts = {}) { // ... }
Score: 3

Emothek (gist)

Developer inattentive and hasty, uses weirds in the code.

Good practice (7)

  • Start all comments with a space make it easier to read.
  • Descriptive with naming.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.
  • Using single quotes '' for strings.
  • Use named function expressions instead of function declarations.
  • console.log more match for production - don't stop the code on return false.

Bad practice (15)

  • Right-side one-line comments.
  • Must have 1 space before the leading brace.
  • Must have 1 space before the opening parenthesis in control statements.
  • Do not pad your blocks with blank lines.
  • Using var can give reassign bugs. Should use let and const.
  • Using // for multi-line comments, instead of /** ... */.
  • Using hard tabs (space character) set to 4 spaces, instead of 2 spaces.
  • Always use const or let to declare variables. Not doing so will result in global variables.
  • Use default parameter syntax rather than mutating function arguments.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Few lines of breaks.
  • Not using tabs in child block.
  • Strange semicolon placing.
  • Math.min(Math.min()) recursion.

Technical examples

  • Spacing before the leading brace and opening parenthesis in control statements if (arrayOfInts.length < 3) {
Score: 2

Anonymous (gist)

Its ok, but must read ECMAscript standarts

Good practice (6)

  • Start all comments with a space make it easier to read.
  • Place 1 space before the leading brace.
  • Place 1 space before the opening parenthesis in control statements.
  • Do not padding blocks with blank lines.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.

Bad practice (13)

  • Leading brace must be in one line with the function declare.
  • Using var can give reassign bugs. Should use let and const.
  • Using // for multi-line comments, instead of /** ... */.
  • Using hard tabs (space character) set to 4 spaces, instead of 2 spaces.
  • Use single quotes '' for strings.
  • Use named function expressions instead of function declarations. disallowFunctionDeclarations
  • Use default parameter syntax rather than mutating function arguments.
  • Functions with multiline signatures, should be indented: with each item on a line by itself, with a trailing comma on the last item.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Must have additional trailing comma at the args to cleaner git diffs.
  • Math.min(Math.min()) recursion.
  • Redeclare Math.max/Math.min without common reason.
Score: 2

Incredible-dev (gist)

Poorly readable code

Good practice (6)

  • Descriptive with naming.
  • Using camelCase when naming objects, functions, and instances.
  • Do not using trailing or leading underscores.
  • Soft tabs with 2 spaces.
  • Functions with multiline signatures indented: with each item on a line by itself, with a trailing comma on the last item.
  • Using try...catch expressions.

Bad practice (17)

  • Not all comments starts with space.
  • Right one-line comments.
  • Should place 1 space before the leading brace.
  • Pad the blocks with blank lines.
  • Place 1 space before the opening parenthesis in control statements.
  • Using var can give reassign bugs. Should use let and const.
  • Using // for multi-line comments, instead of /** ... / and / ... */.
  • Use single quotes '' for strings.
  • Use named function expressions instead of function declarations. disallowFunctionDeclarations
  • Use default parameter syntax rather than mutating function arguments.
  • Using iterators. Should use map() / every() / filter() / find() / findIndex() / reduce() / forEach() to iterate over arrays.
  • Should end files with a single newline character.
  • Must have additional trailing comma at the args to cleaner git diffs.
  • When programmatically building up strings, use template strings instead of concatenation.
  • Var declaration with few lines instead of one-line-one-var case;
Score: 1

2. Read the Content

Stock price (url)

Change wording cases

  • Probably better to change 'No "shorting"—you must buy before you sell. You may not buy and sell in the same time step (at least 1 minute must pass).' with 'Notice : Strict delay before call the function - at least 1 minute. (Case of "shorting" protection).'

Incorrect explanations

  • Hard to understand: must programmer use indeces format in code example or not. In code example indeces not compare with trade opening time.

Mistakes or inconsistencies in code

  • Change 'var' to 'let' in code example.

Product of other numbers (url)

Mistakes or inconsistencies in code

  • I recommend cut name of the function until the 'getIntsProduct()'

Arrays (url)

Change wording cases

  • Probably, more clear if 'You can add as many prices as you’d like.' change with 'You can add an any counts of array items to JavaScript array.'

Incorrect explanations

  • Something wrong with phrase 'Arrays are efficient for looking up the element at an index, because if you know the address where an array starts in memory, it’s simple math to find the address of any index. This gives arrays an O(1) lookup time.'. What meaning by 'address' in this phrase ? Probably better to cut or change with 'Arrays are efficient for looking up the element at an index, in case with knowledge of array structure. This gives arrays an O(1) lookup time.'.

Mistakes or inconsistencies in code

  • Change the 'var' with 'let' in code example.

Garbage collection (url)

The explanation is correct, i understand content after look up first time. But code example look more modern if : conts getMin = (nums) => { let numsSorted = Math.min(nums); return numsSorted; } let myNums = [5, 3, 1, 4, 6]; console.log(getMin(myNums));

3. O notation

Yes. I understand this examples.

4. Content with terms of ES6

What do you recommend we do in terms of ES6? I'm strongly recommend explore and follow the next manuals and guidelines :

https://github.com/airbnb/javascript

https://github.com/mrah/clean-code-javascript

https://google.github.io/styleguide/javascriptguide.xml

https://google.github.io/styleguide/jsguide.html

Explain your suggestion for what we should do clearly and briefly.

As i understand, the common and most popular issue from emails - JavaScript version's compatibilities. For close this issue you can make a switcher in examples with 'javascript old school style code' and 'include ES6 standarts'. Make some notice also, that most modern companies welcome a new style of code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment