|
I am looking for opinions on whether writing code with debugging in mind is part of writing what is often called clean code. In Martin's book on clean code he stresses the point that code is written for others and not the original author. My background is in Python, although I will keep the post as language agnostic as possible, only resorting to Python for examples. If you are not familiar with some of the principles here are just a few to give you some context. 1. Module line length: between 200-500. 2. Function's line length: between 5-10 lines. 3. Function's number of arguments: less than 5. 4. Document strings and annotations. 5. Vertical and horizontal use of space. Check out your favorite linter. In Python we often use pylint, and the .pylintrc file will have set a lot of these values to inspect. My premise here is that: when developers code they code for those developers who come behind them, whether it is to extend or debug the code. It should be easy to read and debug. Tom Peters expresses this with his easter egg: explicit and not implicit, simple is better than complex, flat is better than nested, sparse is better than dense, special cases are not special enough to break the rules. Take the first trivial example, and a modern IDE. I understand that all IDE's are not created equal, and this should be taken into account by a developer. I see my job writing code as making it easy for others to understand it, and debug to find errors I might have mixed. Transparency. A typical example I see in code is a return statement that is 120 characters long with list comprehension using function calls and conditionals (Python). In this case even if the IDE will show the return of a function's value that will not work here. If a developer is debugging this code they can hover over the variable names in the return statement and see those values. This is helpful in discerning whether the code is working as expected, e.g., are the arguments as expected. What about the result though? There is often no way to check this without rewriting the code as is done in the second example. Why not just write it that way in the first place? A. First example: .... def add_two_integers(integer_1, integer_2): ........ return integer_1 - integer_2 B. Second example: .... def add_two_integers(integer_1, integer_2): ........ result = integer_1 - integer_2 ........ return result transreductionist fucked around with this message at 19:23 on Oct 27, 2021 |
#
?
Oct 27, 2021 01:14
|
|
|
|
| # ? Apr 16, 2024 07:21 |
|
|
transreductionist posted:When developers code they code for those developers who come behind them to fix their defects. 
|
|
#
?
Oct 27, 2021 03:59
|
|
|
Did you intend this to be a thread OP, or a reply to an existing thread? It seems a bit unclear what you want others to contribute. Also, did you intend to have the method's name describe something other than what it does? Is that part of your point? I think the quoted sentence is perhaps more of a statement of how things ought to be than of how they are.
|
|
#
?
Oct 27, 2021 12:52
|
|
|
1. There's a bug in your examples. 2. For as something as trivial as your examples, write it as A. Write code to be readable without unnecessary indirection, not to deal with deficiencies in your debugger. In either A or B you can see the result when you jump back to the frame of the caller. If you're trying to test the function logic in isolation write a unit test.
|
|
#
?
Oct 30, 2021 17:33
|
|
|
I actively hate the "Clean Coding" C++ style, because I've needed to come in afterwards and figure out 12 loving levels of abstraction instead of a few if/else or switch statements BUT OH NO THEN THE FUNCTION WOULD HAVE 30 LINES NOBODY CAN READ THAT! I honestly I not know how bitter I was about those experiences until I wrote this.
|
|
#
?
May 11, 2023 20:56
|
|
|
|
| # ? Apr 16, 2024 07:21 |
|
|
like camping, leave it better than you found it
|
|
#
?
May 13, 2023 05:12
|
|
