{CodingBlocks}.NET

iTunes Spotify PlayerFM Overcast Podchaser Pocket Casts iHeartRadio YouTube feed LinkedIn Twitter Facebook Reddit

Navigation

Clean Code – How to Write Amazing Functions

By 71 Comments

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

We continue talking our way through Clean Code, taking a deep look at the building blocks of programming in the quest to write the best functions. Oh, and everybody sings.

The original version of the show notes can be found at:
http://www.codingblocks.net/episode48.

What is your preferred work environment?
vote
×
Live Coding w/ Joe

Live Coding w/ Joe

Podcast News

Clean Code

Clean Code

Functions

  • 1st rule – Functions should be small
  • 2nd rule – Functions should be smaller than that!
  • Functions should barely be 20 lines long…
  • Each function should lead you to the next function in a compelling order – like telling a story
  • They should do ONE thing
  • Code within if’s or block statements should be one line long, meaning they should call another function…overkill?
  • The indent levels of a function probably shouldn’t be more than two tabs! (tabs vs spaces)
  • Prepend “TO” to the name of your function and see if you can describe what it should be doing…it may seem like more than one thing
  • “Another way to know that a function is doing more than one thing is if you can extract another function from it with a name that is not a restatement of it’s implementation”
  • Functions that do just one thing can’t be divided into sections…they’re not long enough
  • Keep functionality at the same level of abstraction – interesting…“getHtml()” vs “getPath” vs path.append(“newline”)
  • The StepDown Rule – the code should read like a paragraph of “To do …” – and those should be at the same basic level of abstraction
  • Switch statements – should be created only once and should be used to create polymorphic objects – objects with the same methods but different implementations
  • Use descriptive names – Ward’s Principle “you know you’re working on clean code when each routine turns out to be pretty much what you expected”
  • The ugliest functions I “write” are refactors – they take too many arguments, because the code isn’t separated by concern – mixing data gathering, logic and presentation!
  • The smaller and more focused a function, the easier it is to name
  • Don’t be afraid to make a long name – a long descriptive name is better than a short enigmatic one
  • A long name is better than a long comment
  • Be consistent in your naming – again, it should be like reading a paragraph – easy to follow

Function Arguments

  • You should basically never use more than 2 arguments in a function – if so, there’d better be a great reason
  • You do this by making values instance variables and then use the instance methods to work with those arguments
  • Testing with multiple arguments becomes very difficult
  • Niladic – no arguments – absolute best case
  • Monadic – single argument – asking a question about the argument, or transforming and returning
  • Other monadic uses are events
  • output variables can be confusing and probably avoided where possible
  • Immediately tells you that the function is going to do something different based on the value of the flag
  • Dyadic Functions – harder to understand just by looking at them…easy to mix up the order of the params
  • Triadic functions – significantly harder than dyadic – avoid if possible – make arguments class members so niladic methods could be called
  • If a method needs more than 2 or 3 arguments, pass in an object
  • When using argument lists, still stick to the same rule – no more than 3 – the list of objects would be your third…n parameter

Verbs and Keywords

  • Naming your functions with good verbs and using the arguments as keywords can be a good thing assertExpectedEqualsActual(expected, actual);
  • Your functions should not have side-effects – if it says it does one thing, it should ONLY do that thing
  • Avoid making methods that require you to inspect the declaration – that means the method isn’t named something that identifies its true intention well
  • Generally speaking, output variables should be avoided

Command Query Separation

  • Functions should do something or answer something, not both
  • Prefer exceptions as opposed to error codes
  • Extract the try/catches out into functions that do the body of work – Throw liberally, catch sparingly
  • Error handling is “one thing” – so it should be the beginning and end of your function

Don’t Duplicate Code

  • One of the biggest problems in programming – duplication leads to multiple places to change and more places where bugs can occur
  • Don’t necessarily stick to the single entry / single exit rule – just make sure the functions are small enough to understand

How do you make functions like this?

  • Revise revise revise. Write your code first and start chopping away at it until you have something that follows the rules mentioned

Tip of the Week

  • Conditional break points with actions. And labels.
  • “Show names of files currently staged: git diff –name-only –cached”
  • MsDevShow Episode on Refactoring with Katrina Owen: https://www.youtube.com/watch?v=LyU3Pk6Wt4M
Share the joy