I am a big fan of good coding style, producing clean, clear code that runs well and is easy to use and integrate into larger systems. I believe that we programmers are essentially craftspeople who should take pride in our work, every line. I am not fond of code that is inconsistently formatted, cluttered with commented out experimental code, and rife with unhelpful or misleading function and variable names. But I sometimes find it hard to argue with code like this that basically works.

If you think that coding style matters, I am looking for recommendations for ways of teaching good, professional coding style to the junior programmers under me. I want them to take pride in their work, but my concern is that they appear to become satisfied when their code just barely works, and seem to have no interest in producing what professionals like me would consider professional code. On the other hand, if you think coding style is not particularly valuable, I welcome your comments and am open to reconsidering my standards and tolerances.

I know the usual arguments in favor of good code: comprehensibility, ease of maintenance, etc., but I would also like to hear some rebuttals to arguments like "it works, what more do you want?"

In our industry we can use the compiler to hide a multitude of sins. Clean code and messy code can both lead to identically functioning programs, so does cleanliness matter, and if so, why?

[While there are several existing questions on coding style, I didn't find any that related to teaching methods and ways to instill good coding style in junior programmers.]


  Make a good impression


Take some of the well-known books, e.g. Clean Code, Code Complete, Coders at Work, The Clean Coder: A Code of Conduct for Professional Programmers etc. (see here for full lists) and give them a couple of days to read one - at work, in a private office.  Space those out, say 1 book a month or a quarter.  They will see from the effort that what you're personally saying is really important, not just "the company line" to take with a grain of salt.  Obviously make sure you've got management in line with this - you don't want them saying in passing "huh? what's person X up to? holed away in there with the door closed?"  

Along with continual, more formal training classes in the latest technologies.

Also, as things are done "the right way" gave big encouragement and even rewards.  Otherwise it can be more of a negative, punishing, rather than positive, rewarding environment.  Most folks want to do and want to be known for doing "a good job" if they have the tools to do it.


  Practice what you preach, Preach what you practice


Talk about code, talk about the good principles, talk about new tools, become 'known' for it.

Provide / support /suggest screencasts, videos, peepcodes and whatever online tutorials and classes you can find.

Support and suggest appropriate local user groups, including those on sites like http://www.meetup.com

If you are in office (i.e. not virtual) a well-stock bookshelf of the actual books you would like people to use is good.  Find a way to make this be "not just dusty bookshelf in the corner" but placing it really prominently, Moving the books around,etc.  Use your imagination too.  Maybe every programmer gets one book as 'homework' a month and you have a monthly meeting where they get to 'present their findings' !  

This will make far more of an impression that any 10 minute conversation alone and it will remove you from the 'criticizer' role and allow them to learn how to fish for themselves (rather than giving them fish, you know the deal).  Some junior folks also find it intimidating to have a senior folk always explain stuff, when sometimes all they really want is some time to study, practice and absorb it.


  Instill a culture of learning and excellence


Basically you want to create "a culture of learning and excellence" so that you can Practice what you Teach and inspire others to do the same.

This should be in conjunction with code reviews to see if/how the principles apply to the actual work being done.  Conversely, code reviews done without the above can feel like whipping sessions to the student no matter how well intentioned by the teacher.
