Coding styles
-
Like what? (Just askin'.)
PIEBALDconsult wrote:
Like what?
I've read a really good blog about this, but I can't find it now. I'm going by memory. The first potential (but very minor) benefit happens because of the way the JIT compiler works. If you have the following code
if (x) A(); else B();
then only one of the methods (A or B) with be compiled the first time that it is executed. With smaller methods there is also a greater chance that CPU registers will be used rather than normal memory. In addition to this there is the inlining which I have already mentioned. So, in some cases smaller methods can out perform larger methods, and most of the time it's probably hard to tell which will perform best. I always code in a way that is easy to read/maintain because that is what we spend most of our time doing and the performance difference is not worth worrying about 99% of the time. In addition to this it's also worth remembering how slow other things are. If your code does database queries or uses files then the additional time to call another method really isn't going to make a difference.
-
I often work with smelly code. One of the things that really stands out to me in the smelly code is long functions/methods. A method will often span many screens and I find it very difficult to follow. My code used to be like this... when I was at school. I used to think I was a very good coder because I could write long and complex methods. These days I haven't really got the patience for it. Why should I have to work with this code? Coding for me these days is more like a piece of art or a story. My methods tend to be very small, sometimes one or two lines. I do wonder whether I have lost some of my ability to work with long methods. Is working with bad code a skill that needs practicing? How would other people see my code? My coding style is very unique compared to what other people on my team do. Although it looks good to me will they find it difficult to work with? Will it be hard to understand if people have never seen this style before? When I'm changing code I also like to improve (IMO) it, I will use the 'extract method' feature in places to make it more readable. What will people think of this though? They may think I am spoiling 'thier' code.
A lot of methods that are only 1 line long can be a little annoying too. Of course if it's a public interface and you want to protect your right to change implementation, then it should still be a method. And there are other good reasons, but just breaking up the code "because you can" isn't a good reason. You might imagine a large house of 10,000 square feet. If that were just one huge room, the house wouldn't be very usable. If there were appropriate sized rooms, of 100 to 300 square feet each or so, then you have a very usable house. If you have many rooms of only 4 square feet each, then you once again have an unusable house. In other words, break it down to an appropriate level, but no more. There is a quote supposedly by Pascal that goes something like "I'm sorry this is so long, I didn't have time to make it shorter." Making good methods that are short enough (but not too short) takes time to do correctly. Yes, reading and maintaining long code (or any code) is a skill. You might want to look at Brownfield Application Development in .NET by Belchem and Baley. What do you mean when you say your code is "very unique"? All else being equal, being different is not good. All it does is slow people down as they try to read a style they're not used to. So they might find it hard to work with, but if you're doing something good then maybe they should be copying you. My kneejerk response is that you're trying to be too clever. Clever is sometimes good but usually not.
modified on Wednesday, November 17, 2010 9:50 AM