Changes between Version 32 and Version 33 of HowtoGoodProgrammingTechniques
- Timestamp:
- Feb 14, 2026, 1:19:36 PM (2 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
HowtoGoodProgrammingTechniques
v32 v33 11 11 I follow a simple, five-step procedure for every new function I write: 12 12 13 1. '''Write''': First, I implement the core idea to get it working. The initial goal is just functionality , a clever thingis to keep in mind the core structure it should have in the future.14 1. '''Refine''': Next, I improve the code's structure, ensure correct return values, and format itfor readability.13 1. '''Write''': First, I implement the core idea to get it working. The initial goal is just functionality; a clever approach is to keep in mind the core structure it should have in the future. 14 1. '''Refine''': Next, I improve the code's structure, ensure correct return values, and format the code for readability. 15 15 1. '''Clarify''': I choose descriptive names for variables and functions. This step can be slow, but it's one of the most valuable programming practices. 16 16 1. '''Document''': I add comments where necessary to make the code easy to understand. … … 53 53 54 54 55 == Human factors ==55 == Human Factors == 56 56 57 57 === Memory === … … 59 59 You won't remember exactly what a piece of code does or why it's there weeks or months later. While comments help, they can be forgotten or become outdated. 60 60 61 Always keep your comments updated , now we have tools that automatesthis task.61 Always keep your comments updated; we now have tools that automate this task. 62 62 63 63 === Visual Readability === … … 72 72 Similarly, `if` statements and other control structures should be visually distinct so you can immediately see where they start and end. 73 73 74 Add functions to long parts of the code inside the loops, but only when the loop is not an optimization-required one.74 Extract long parts of code inside loops into functions, but only when the loop is not performance-critical. 75 75 76 76 … … 89 89 Variable and function names are very important. A good convention is to make names as short as possible while remaining perfectly understandable. Think of a hierarchical structure, like in object-oriented programming, where names go from general to specific, often ending with an action. 90 90 91 It is good practice to review the final code, brainstorm their names, and rename variables, functionsand global variables once a major part of the application is complete. This helps ensure a consistent and optimal naming structure throughout the codebase.91 It is good practice to review the final code, brainstorm names, and rename variables, functions, and global variables once a major part of the application is complete. This helps ensure a consistent and optimal naming structure throughout the codebase. 92 92 93 93 … … 104 104 Often, good function and variable names seem to be in the reverse order of how you would say them. If in doubt, imagine a list of similar names sorted alphabetically. This can help you see which parts of the name should come first. 105 105 106 It's also helpful to know a variable's type from its name. Some conventions use suffixes for this, such as `_v` for values, `_a` for arrays, `_d` for directories, and `_f` for files (a form of Hungarian notation). Use a `_` prefix for unimpor ant local variables.106 It's also helpful to know a variable's type from its name. Some conventions use suffixes for this, such as `_v` for values, `_a` for arrays, `_d` for directories, and `_f` for files (a form of Hungarian notation). Use a `_` prefix for unimportant local variables. 107 107 108 108 … … 110 110 Large applications are difficult to maintain and debug. The best way to avoid these pains is to: 111 111 1. Keep everything modular and independent. Every function, tool, or feature should be callable independently without relying on other parts of the application. Consider using external commands to achieve this. 112 2. When calling external commands or global tools, include a debug entryentry of the call with its arguments. This makes it easy to reproduce the call outside the application for debugging.113 3. Avoid deleting or renaming old functions that other tools might depend on. Instead, mark them as deprecated, have it tocall the new function with the updated parameters, and add a warning message to inform developers of the change.112 2. When calling external commands or global tools, include a debug entry of the call with its arguments. This makes it easy to reproduce the call outside the application for debugging. 113 3. Avoid deleting or renaming old functions that other tools might depend on. Instead, mark them as deprecated, have them call the new function with the updated parameters, and add a warning message to inform developers of the change. 114 114 4. When refactoring a function, do not change the final behavior. This can cause unexpected results in applications that use the function. 115 115 … … 138 138 * It always takes longer than you expect. 139 139 * Existing users become frustrated. 140 * Refactoring changes your code and behavio ur.140 * Refactoring changes your code and behavior. 141 141 * You don't control the rewrite; it controls you. 142 142
