A matter of style
Join the DZone community and get the full member experience.Join For Free
I’ve had a few interesting discussions about coding style lately, which inspired me to blog about my views on the issue. I’ll start with an unattributed quote:
You can write Fortran in any language.
This roughly translates to: You can write crappy code in any language, no matter how sophisticated or en vogue it is. Really, you shouldn’t, but this leads to the conclusion that the programming language does not influence code quality as significantly as some people might think. Does this mean that once you’ve learned to write code, you should stick to your style and adopt it to every language you use? A resolute no from me.
- You will have the right tool available for the problem at hand. Every language and platform has its strengths: System programming in Java is pretty pointless, just as web development is in C++. It is possible, but there are better tools for the job. If you know only one language, you will probably not even see that there is a superior alternative. If the only tool you have is a hammer, you tend to see every problem as a nail.
- It’s good for you. Looking into different ways of thinking and learning new things will make (and keep) your brain flexible. Eric Raymond once said that “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.” I agree.
- You probably won’t treat your language like a religion, because religions are usually mutually exclusive.
I’ve done considerable stuff with Python, PHP and others as well, but I’m willing to let my skills with these rust in order to get as much practice as possible in my languages of choice. The paradigms are what’s really important in my opinion though, not the languages. (Although drastically different syntax might help to stay open-minded.) I’m currently covering structural programming, object-oriented programming, functional programming and generic programming.
It’s probably a bit cheesy, but I’m going to compare programming to martial arts. (Sorry, couldn’t resist; I’m comparing everything to martial arts since I started to read The Book of Five Rings.) Just as in martial arts, there are numerous styles and forms of programming, with no ultimate consent on what the best one is. It often depends on the problem at hand. Another similarity is that martial arts (at least Asian ones) usually employ a philosophy at their core, just like many programming languages do. C, for instance, is very concerned with the KISS principle and the UNIX philosophy.
If you take the philosophy and programming style from C to Java, your code will be a mess. Not because Java is a bad language, but because Java was not intended to be a language to write C in. It has different purposes. You can’t master Karate and then claim to do Aikido while punching people in the face. You will have to accept that Karate is just not appropriate in an Aikido dojo, so no matter how good you are at Karate, you’ll have to invest energy into learning Aikido.
Another cheesy analogy: How would you go about moving to a different country? I would try to learn the language and behave in a way that is considered to be polite by the locals. Of course, I could just keep talking in my language and do whatever I always do, even if it offends everyone around me. So why would anybody use goto extensively in C++? It’s possible, but it would offend almost every C++ programmer I have ever known.
I think it is appropriate for a journeyman (and if you’re learning a new language, you are one in at least one community) to learn from the respective masters and try not to be ignorant. Everyone is free to disagree (especially constructively), but I think you should at least give it a try – you will have an easier time being accepted by the community and hence an easier time learning. That’s at least my experience.
So how do I avoid the problems mentioned above? I adopt the style of notable authorities of the language. I write C like Kernighan & Richie, C++ like Stroustrup, STL and Boost, Java according to the Sun conventions etc. These people are certainly not inerrable geniouses, but they are the ones creating the core community around and probably thinking the most about the language.
I don’t use camel case in C++ although it has less issues than underscore notation. When I wrote some C# recently (Mono of course), I actually started method names with an upper-case letter, although I don’t like it. It’s all about the consistency, can you honestly look at code at code that mixes different programming styles? I can’t.
This is not only about brace placement placement and naming: When working with Java, I write accessor methods, but I prefer structs with public member variables in C++. Partly because it’s more common, but also because there are some good arguments for accessor methods in Java, and few in C++. (That being said, I largely avoid public fields and accessor methods alltogether because they are rather evil.)
I usually come to the conclusion that the respective language’s conventions make sense, so I’m not sure how I would treat one with bogus conventions. I probably wouldn’t use it.
All of this is only relevant for people in charge of code style (e.g. because they are working alone). When working on a team, it is in my opinion of the utmost importance to use consistent conventions, even if they’re weird.
Opinions expressed by DZone contributors are their own.