CodingBlocks
CodingBlocks
Episode 48 – Clean Code – How to Write Amazing Functions
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?
- Love me some cubicles
- Open Floor Plan, collaboration!
- Home office (pants optional)
- A work office, with a door
- Coffee / Tea Shoppe
Live Coding w/ Joe
Podcast News
- iTunes Reviews: BrokenDev, Simontheu, Hruncito, TerrenceD, Rich11145, HardCoreRockstar, Bcmsco, FriendofEntropy, Fredstban, Ibankai7, Islander201111, Iamqaz, Adam Hannigan
- Stitcher Reviews: snapper109, brianplace, veso7, Zelig880, Cube00, joro550, philipLowney, RocketRaccoon
- Joe made a video: https://www.youtube.com/watch?v=B3C5r7gzidg
- And don’t forget to subscribe! http://www.codingblocks.net/youtube
- How to become an engineer at Google from Peter Nelson
- ATL Code Camp – You can still register?! maybe?! Oct 15th https://atlantacodecamp.com/2016/Register
- Connect.tech – Oct 20-22nd http://connect.tech/
- Your web browser hates your SSD https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/
- Allen’s tip from last episode oauthforaspnet.com is not working
- Allen made MVP…what?! https://mvp.microsoft.com/en-us/
- Leave a comment for a chance to win 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=LyU3Pk6Wt4
