• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Clean Code : Who follows the boy scout rule?

 
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A colleague and I attended a 2 day Clean Code workshop last year with the man himself, Uncle Bob, and while I learned a lot about what constitutes 'clean code' I must say that the biggest takeaway item I got was this:

The Boy Scout Rule (for programmers): Check in your code a little cleaner than you checked it out
(Clean Code - Page 14)

The realisation that by doing this this every time we committed new work we are actively reversing the rot was no small boost in confidence. Knowing you're driving your codebase to better things every day was, and still is, a huge motivator for the whole team.

So, my question to the readers is: Do you follow the boy scout rule?
 
Bartender
Posts: 2407
36
Scala Python Oracle Postgres Database Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, sometimes...

It depends on the code. Some code is clear enough so that you can at least see where there might be a problem, in which case I'll try to fix it if it's reasonable to do so in the time before my manager demands results from whatever task I was supposed to be doing in the first place.

But some code is just so awful or complex that you simply have no idea where to start, or it's an area where you don't feel you know enough to improve it, in which case I'm afraid it's over to some other poor sod to fix it, unless I have enough time to investigate/learn/fix/test things properly.

It's a good rule to follow though, as it will also help you to learn a bit more about the code and - over time - make your own job easier as you start to use your new improved code instead of the nasty old crud you found there originally. And of course it allows you to give other programmers plenty of opportunities to follow the same rule by fixing your crud!
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends. If I notice something, yes. Even if I'm just adding a comment or a TODO.
 
Greenhorn
Posts: 15
Angular Framework Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my case it's pretty much the same as chris webster described.

I find myself often improving the code that is already ok / not so bad. Whereas I do not touch the code that is clearly a mess, just because I'm afraid of the amount of time it will take.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My wife is always telling me that she wishes that I'd put as much effort into cleaning up my office as I did in cleaning up code (mine and others'). Seems like cleaning up code is all I ever do nowadays. It's a crappy job but somebody's gotta do it. There's plenty of messy code out there and it seems like more messy code is written than is cleaned up, a discouraging thought to say the least. (wild-a$$ guess) 95% of the programmers I meet just don't care enough to write clean code or clean up after themselves. The trick is to pick your battles. I only insist on cleaning up code that is critical to completing the task at hand. Other messes that we see but won't be touching soon are left for another day.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes. No. Maybe. It depends.

It's a double-edged sword. While the urge to make the code better is strong, the risk of inadvertently adding regressions is real. Of course, that can be mitigated by having a good set of regressions tests -- but really, how many systems have you worked with that have decent regression coverage?
 
Tim Cooke
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You raise an interesting point Bear. 'Cleaning up' production code without test coverage is risky, and often too dangerous to justify the perceived benefit. However, it is my view that the test suite is as important a part of the codebase as the production code itself so I would consider that writing a regression test for some uncovered code is a valid improvement even if you don't change the prod code.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You will get no argument from me on that point -- but in reality, how many places have you worked where test coverage is that good? My current contract (coming to an end soon) likely has the best test coverage of any system I've worked on, but it's still marginal at best. Most other places I've worked have zero test coverage, or at best, a handful of high-level tests.

It's a sad state of affairs.

Maybe I can change that at my next gig.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cleaning up code is always easier when it's backed up with a set of tests that you can rely on to break if you messed something up. That's why TDD is a very important practice for me -- when we do code cleanup, we always start with whatever unit tests are available. If there are none, we'll *try* to write some around the things we plan to clean up. Unfortunately, a lot of code is just too tightly coupled that it makes writing unit tests for them extremely difficult to impossible. This is where frustration builds up. Michael Feathers' WELC book has been a lifeline for me over the years as well as Joshua Kerievsky's "Refactoring to Patterns". In the worst case scenario, the only thing we end up doing to clean up the code is to do a few simple "extract method" and "rename" refactorings. Still, that's better than nothing.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic