Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
transreductionist
Dec 30, 2015

Be patient with the machines; if only for the fact that in the years to come you will want them to be patient with you. -- Allen Turing


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 18:23 on Oct 27, 2021

Adbot
ADBOT LOVES YOU

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply