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

qsvui
Aug 23, 2003
some crazy thing

transreductionist posted:

When developers code they code for those developers who come behind them to fix their defects.

:thunk:

Hammerite
Mar 9, 2007

The game Monopoly sold for $2 in 1935. In the box, you get monopoly money.

That original stack of monopoly money from 1935 is worth $50 as a collectors item.

Monopoly money literally holds more value than the US Dollar.




Jade Ear Joe

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.

ExcessBLarg!
Aug 31, 2001


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.

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