Ever judged a book by its cover? Of course you have. Ever passed judgement on some code simply because it didn’t look pretty? There’s more to writing code than having it functional and in this episode we dive into the reasons code formatting actually matters. Who wins the newspaper format debate?! Leave us a comment and let us know!
For the full show notes visit:
- Husain and Mike – Check your email!
- Shout out to AngryZoot! We just haven’t mentioned her in a while, and she’s awesome – and does martial arts
- Cynical Developer – James Studdart – Cake, XAML, React (Zac Braddy)
- Mark McDow – Winner of the O’Reilly Software Architecture Convention – $1700
- Maurizio Pozzobon – Code Maid retraction
So – you should probably follow us on twitter, or join the mailing list!
Michael attended DevFest 2016 – Google Developer Group
Secret Back Door in Some U.S. Phones Sent Data to China, Analysts Say
Allen attended MVP Summit – amazing
- Did some F#
- F# Dojo with Fractal Trees:
- Did some Bot programming – cool stuff
- Uhro Sharp – 3D programming in C#
- Visual Studio for the Mac?!
Reply All – Pepe the Frog
Want a Coding Blocks sticker?
Send us a Self-Addressed-Stamped-Envelope
Clean Code – Drawing!
Oddvar Tengesdal won a copy of Clean Code!
Programming Beyond Practices
- If your code is a mess, then people will assume that your attention to detail in how the app was coded is also a mess – perception
- Teams should adopt formatting rules and follow them
- Automated tools help with the process
- “Code formatting is important”
- Code formatting has a direct affect on maintainability and extensibility of code over time
- Try to keep max length around 500 lines long and smaller is better – FitNesse app is in this range
- Tomcat and Ant – several thousand lines long and at least half are over 200
- Newspaper metaphor – read it vertically – headlines at the top detail increases as we go down the page
- Separate concepts with blank lines
- Closely associated code should be grouped together so it’s dense
- Concepts (methods) that are closely related should be grouped as closely together as possible to keep from hunting through files
- Variable declarations should be as close to their usage as possible
- If the methods are short, then the variable declarations should be at the top of the function!
- Control variables for loop should be defined within the loop
- Instance variables should be declared at the top of a class
- When one function calls another, those should be close vertically in the file
- Conceptual affinity – when methods do similar things or are named similarly, they should also appear close to each other
- Vertical ordering of methods – the caller should be first, then the callee, and that method’s callee, etc…on down the page
– Death of Macbook Pro?
– The beginning of a new awesome era?
- How wide should a line be?!
- In the popular projects examined, it appeared that 40% of lines were between 20 and 60 characters
- Another 30% of lines were less than 10 characters…
- Author suggests that beyond 100-120 is careless
- Put spaces on both sides of an assignment operator (equals sign)
- Don’t put spaces between the function name and the parens
- DO put spaces after individual arguments / parameters in a list – shows they are separate
- Also use spacing to indicate the precedence of operations – think of spacing in math equations with several parentheses – author calls it out for order of precedence, I actually don’t like this one – I prefer grouping with parens
- Lining up variable declarations, names, types – found that it was distracting to the “story” of the code….I agree
- Hierarchically lining up code based on it’s scope – super important
- Author would sometimes condense multiple lines into one (like a get; set;) eventually set it back for readability (breaking indentation)
- What about for PRINT statements in SQL???
while statements – indent the semicolon on the next line…otherwise they’re hidden
- Follow the team’s formatting rules…don’t go vigilante
- He threw in Uncle Bob’s formatting rules
Resources we Like
- Clean Code
Tip of the Week
- Michael: Chrome Debugging – Break on Attribute Modification
- Allen: Enforce code formatting amongst many editors for people on a team – from Gustav in our Slack community
- Joe: Coding Math on Youtube: