# Final Review Notes

Below is a summary of most of the items the TCC checks for during a final review. It's just a general guide of what to check for during a final review and does not need to be stictly adhered to. Everyone has their own style of reviewing, and as long as the reviews help maintain high-quality articles, and identify potential article issues before the article reaches the users, then that's good enough.

Any uncertainties during a review can always be left in the closing review comment to request that the TCC looks more closely at these items before adding final approval.

## First Pass Skimming the Article

- Read the article from the perspective of a reader and ask questions that a reader would ask.

- If it seems like magic how the author knew to use a certain data structure or algorithm, then suggest a possible addition of information or rewording to help address the issue. It should be reasonably easy for a reader (of the target audience) who does not know how to solve the problem, to follow the logic throughout the intuition.

- If the approaches are related (usually they are) is it easy to transition from one approach to the next? i.e. DFS & Union-Find to solve the same problem may not be related, but solving a problem with top-down DP (memoization), bottom-up DP (tabulation), then make sure the order in which the approaches are written seems reasonable, and the transition from one approach to the next mentions the motivation for the current approach (i.e. what makes it an improvement over the previous approach, or vice versa).

- Is it easy to transition from one approach to the next? Saying "Now let's solve this using bottom-up" is not a very smooth transition. Instead, it is usually better to identify the inefficiencies of the previous approach, discuss the intuition for how we could address those inefficiencies, and then introduce the new approach.

- Does the article contain an intuition, algorithm, code, and complexity analysis for every approach?

- Are the subheaders appropriately descriptive? If something seems off, I'll scan the discussion section to see if there are user complaints in the comments saying "This should not be called ... because ..." and then maybe suggest a different name. Most of the time, it's okay to just leave these as is.

- Would an overview section improve the article?

- Visual aids:

- Are they helpful?

- Is there a part of the article that was confusing that could benefit from a visual aid? i.e. if the approach is particularly tricky, an example slideshow can be very helpful.

- Are there any typos?

- Are the colors too vibrant (uncomfortable to look at)? This is almost never a problem, but in general muted colors can make an image look much better. [Click here](https://github.com/leetcode/oj-solutions/pull/976#pullrequestreview-791236347) for an example. The initial colors are okay, but they are intense. The alternative muted colors feel more "comfortable."

## Pre-review

- Look at the discuss section and identify the approaches that would be reasonable for an interview. It is important for the Author or the First Reviewer to identify when an important approach is missing or when there are too many approaches, since changes in the final stages are more costly. If you're uncertain about whether something should be included ask the Technical Content Coordinator (TCC). On the flip side, if two approaches are very similar, consider writing one approach and mentioning the other approach as an alternative, having two nearly identical approaches back to back makes the article unnecessarily long. However, if the similar approach is needed to help guide the reader from say the 1st to the 3rd approach, then it might be worth including.

One of the tricky parts here is a two part balancing act.

1. Effort versus Gain: We need to decide if the amount of effort the author will have to put in is less than the amount the article will improve by having this change made.

2. Author Morale versus Gain: Asking an author to do extra work to remove an approach (less pay) can be demotivating for authors. If the issue only arrises occasionally, then I think it's best to let it slide, and just mention, "it is probably fine to keep this approach for this article, but for future articles, it's good to keep in mind ...". And if the author repeatedly tries to include unnecessary approaches, then send them back to trim down the article. <br><br> Anyways... a few excess approaches here and there are okay, so long as it doesn't become a trend.

## Second Pass Read Through

- Read the code line by line:

- Does it look clean?

- Are there any steps that seem unnecessary?

- Some common checks:

- Opening and closing playground tags?

- Are there identical sections of code? If so suggest writing a function to perform that step and replacing those sections with the new function.

- Tracking visited elements? Use an array of booleans or a set. Do not use a map or an array of integers to track something that could be tracked with a single boolean. This is in general a good rule of thumb, and actually offers a substantial space optimization for languages like C++ (and sometimes Java) where booleans might only use 1 bit.

- Evaluating if something is true/false? Do not use `condition == true`. If the condition is true, then there is no need to check if it equals true.

- Python: do not assign a lambda function to a variable name. Only use lambda when passed as an argument or in a place where it does not need a name. If a function has a name, use the standard `def function_name(parameters):`. This does not matter as much here, but it is good practice in general. Because lambda functions do not have a name, in python, it can be difficult to pinpoint an issue that arrises from a lambda function when the code base is large or there are a lot of lambda functions.

- Does it use meaningful variable names? (See next bullet point for more details) and do those names match the names used in the algorithm section?

- Are the functions appropriately typed?

- Python: Use typing conventions that match the default.
- C++ and Java: Use `auto` sparingly. Writing out the type (when the type is not too complex or long) will generally help improve readability.

- For the languages you do not use, skim the code line by line and check for:

- Comments: Are they helpful? Do they look clean and free of typos? Are there way too many or too few? (just use your best judgment here)

- Spacing, indentation, and brackets. You are encouraged to check out the Google style guide for each language.

- https://google.github.io/styleguide/javaguide.html
- https://google.github.io/styleguide/pyguide.html
- https://google.github.io/styleguide/cppguide.html
- https://google.github.io/styleguide/jsguide.html

- Are there any lines over 100 chars? If so suggest it be shortened. (Note LeetCode allows for 100 chars across all languages, this differs from the Google Style Guide which varies between 80 and 100 characters depending on language). Although, if an author prefers to stick to 80 characters, that's okay too, so long as the code is readable and clean.

- A few common checks:

- C++ use static_cast instead of (type)
- C++, Java, JavaScript all use lowerCamelCase for variable and function names. (this differs from Google)
- python uses snake_case for variable and function names (except for the default function since this must be copy-paste-runnable)

- Meaningful variable names.

- If you're iterating over a 2D array, use `row` and `col` instead of `i` and `j`. Likewise, `rows` and `cols` is preferred instead of `m` and `n` for the number of rows and columns.

- If your indices represent the left and right bounds of something, consider using `left` and `right`

- Example, what does `dp[i][j]` contain? What does `max_coins[left][right]` contain? The names don't have to be perfect, but choosing meaningful names will help imrpove readability.

- Exceptions:

- If you're iterating over a 1D array, a list, a string, etc., then a one letter variable name for the index is fine. Although if you're iterating over the elements specifically, consider using a meaningful name for the object i.e. `for word in some_list` or `for letter in word`

- Common function names use your judgment, i.e. if the job of `dfs` or `bfs` is to sum the values of leaf nodes consider calling it `sum_leaf_nodes`. That said, sometimes it can be difficult to think of a more meaningful name in which case generic names like `dfs` or `bfs` are fine.

- Walk through the complexity analysis:

- Common things to check for:

- Does it seem reasonable?

- The space complexity does not include the sapce used by the input or the final output. A good rule of thumb for space complexity, is if we converted the function to a generator (so we always yielded the elements in the final result as soon as they are calculated), how much space would we use? With this in mind, when we have to do something like reverse the final result list before returning, then the output does count towards the space complexity. But most of the time, it's safe to assume that it does not.

- The space complexity includes space used by sorting. If the space used by sorting is negligible, then sometimes it's okay to not mention this. But it never hurts to mention that sorting does require extra space since this is something many new users will not know.

- If a languages has a different complexity, discuss why. This is a common scenario when regarding the space used when sorting an array in place.

- Uses $$O(n)$$ instead of $$\mathcal{O}(n)$$.