Skip to content

Latest commit

 

History

History
25 lines (13 loc) · 3.05 KB

CODING_INSTRUCTIONS.md

File metadata and controls

25 lines (13 loc) · 3.05 KB
Raw

Coding Instructions

  • If we do not provide sample input/output in the problem, make reasonable assumptions. If we do, they are still just guidelines, so feel free to make reasonable changes.

    • Your goal isn't to pass some automated test-case checker: instead, it is to build something that will be intuitively useful to other people, and so use your best judgement.

  • Please abide by the style guide for your preferred language.

    • Why? Code is written only once, but read many many times, and so we want to optimize for that. If everyone follows the same conventions while writing code, it makes other people's code look like your own, and therefore, easier to understand.

    • A good analogy is that writing code without following a style guide is like using texting language in professional communication ("whr r u", instead of "Where are you?"). No one will take you seriously. Which is why this needs to become a habit ASAP.

  • Please create useful variable / function names.

    • When you're working with larger codebases, no one has the time to read all the code. Which means that you have to infer reasonable behavior based purely on names. And using proper descriptive variable / function names is the first step in making that possible. Not doing so would mean that other engineers cannot trust your code, which is not a situation you want to put yourself in.

    • Ask yourself: Is it possible to figure out what this variable contains based on just the name? If no, then it means that your variable doesn't have a good name. Avoid abbreviations if possible, since they introduce ambiguity, forcing the reader to figure out what you meant based on context (eg - cmp could mean compare, comparator, compulsory, etc). In almost all cases, temp (along with all its variants) is a bad name, because it tells me nothing about what it contains.

    • Similarly: Given just the function name and appropriate context, if you ask someone else to implement this function, will their code match yours (adjusting for minor differences)? If no, then your function doesn't have a good name. One important observation here is to never do something inside a function that isn't expected by just reading the name (eg - your check function should never print anything).

  • Please write well-structured code with clean abstractions.

    • What does that mean? The person reading your code should know how it works based purely on an understanding of the problem, and the API you provide. The fact that one does not have to read the internals of your code to understand it, is nice consequence of making the reasonable choice at every point. And this is extremely valuable while debugging complex systems.

    • Additionally, make sure that your code is resuable: that it solves more than just the exact problem you are working on right now. In real life, requirements are always changing, and you want to make sure you can handle that with minimal effort. To simulate that, I will always evaluate your code at a higher standard than the problem statement given to you.