Best Practices For Coding

Variables & Classes Names

1. Choose descriptive and unambiguous names.

2. Make meaningful distinctions.

3. Choose descriptive and unambiguous names.

4. Use pronounceable names.

5. Use searchable names.

6. Use nouns for classes, packages, and variables

7. Use verbs/verb phrases for functions.

8. Avoid unpopular acronyms and other names that don’t make sense.

9. Avoid using confusing letters for names.

10. Avoid meaningless prefixes or suffixes.

Code Formatting

 

1. Group code by their functionality. Related functions must be close. Related code must appear vertically dense.

2. Declare temporary variables close to their usage.

3. Adapt company/team-wide code conventions. Agree on a common standard for code-formatting. 4. Either use an external tool or IDE options for auto-formatting.

5. Avoid too long files. 1000–2000 lines are okay. Shorter, the better.

6. Avoid too-wide code lines. Make sure they fit into the screen (Up to 70 to 120 characters). If they don’t fit, try to split them into multiple lines.

7. Write high-level code first in a file and keep lower-level implementations towards the end of the file. (Good files are like newspaper articles, with a heading, the important stuff first, and details later)

8. Make sure the code is ordered as of the calling sequence. The caller should be before the callee.

9. Follow proper indentation across code files. Use an external tool or IDE’s support.

Error Handling

 

1. At lower levels, throw exceptions instead of returning error codes. Keep error codes for communication between different layers, interfaces, or systems.

2. Errors and exceptions must provide adequate context (such as intent, failure stage, error type, failed values etc.)

3. Map foreign errors to adhere to common standards. Wrap all errors and exceptions raised from external systems, third-party libraries, and APIs. Use a generic error type for unknown/unhandled cases.

4. Reduce the reliance on return type and null checks (since they strongly couple failure path information to main flow). Instead of returning null/false, return a proper error object or throw an exception. Passing null to a function / next stage is also bad, avoid such practices.

Comments

1.Express yourself in the code, but not in the comments. Keep comments for delivering any extra information. If the code is readable, the need for comments is very low.

2. Warn the consequences of potential scenarios/actions. If the code is too brittle, instead of commenting, fix the code.

3. Avoid noise and weak comments (negativity, complaints, humour, misleading opinions, redundant statements, changelog, too much information, irrelevant facts, comments needing additional explanations).

4. Avoid commenting out code chunks. If code is bad, rewrite it. Use version control systems for handling code that is expired, deprecating, or experimental. (Protip: If you comment out code for a very short term, consider using a TODO comment as a reminder to clean things up later).

 

 Read More :: Sublime Text 3 Plugins That Every Developer Must Use

 

 Read More :: 13 VSCode Extensions That Every Web Developer Should Use