def longVariableNamesEverywhere(*args):
Not a substitute for docstrings and code comments.
#TODO: insert witty and legible code.
#TODO: learn to read code.

return "Rant and self-deprecation complete."

  • 0
    Damn, devrant eliminated my syntactical whitespace, this is just gonna throw syntax errors now.
  • 2
    For private/internal code, I disagree. Comments have a high probability to evolve into a lie over time (code gets updated, comments don't). The chosen method of source control should be where most of the comments reside (issue tickets, commit descriptions, etc). The code itself should be the documentation wherever possible. If it seems impossible to achieve that without in-line comments, it's often a smell that it could be refactored into something simpler/easier to read.

    On the other hand, public-facing code consumed by other applications should have comments explaining the constructor(s), method(s), and parameter(s) and return value(s) involved.

    But hey, you code your way and I'll code my way and the Sun will still rise and set every day.
  • 1
    @duckWit yeah makes sense, just tired of trying to unravel spaghetti that probably could've been explained with like a couple comments. But good on you for thinking ahead.
  • 0
    @noobrants yeah spaghetti code is evil.
Add Comment