Coding styles
-
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.
I can't smell a question here.
I know the language. I've read a book. - _Madmatt
-
I can't smell a question here.
I know the language. I've read a book. - _Madmatt
I'm interested in peoples thoughts. Other people must be in similar situations too.
-
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.
-
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.
-
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.
Member 4487083 wrote:
I used to think I was a very good coder because I could write long and complex methods.
If you're writing long complex methods, you're not breaking down your problems correctly. If I was supporting your code, I'd have to hunt you down and remove your DNA from the face of the earth.
Member 4487083 wrote:
How would other people see my code?
The above pretty much sums it up...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
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.
Methods that are only one or two lines long probably means your call stacks are absolutely huge and debugging probably feels like a huge expedition. Spaghetti code gets its name not only because of the length of the noodle, but the number of noodles in the bowl. What are your criteria for breaking functionality out into its own method? Length of method is rarely the best way to decide. Do you use UML or anything to document your code? Are these methods usually private or public? Do your classes and methods make sense when you describe the functionality in a sentence? For instance, a Dog object has a Tail object property which has a Wag() method. So a dog has a tail than can wag.
-
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.
Member 4487083 wrote:
one or two lines
That's probably too short. How often are they called? From how many places? When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro. :-D
-
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.
-
That looks good. I've used the code metrics in Visual Studio which has the cyclometric complexity, but it looks like this does a bit more.
-
Methods that are only one or two lines long probably means your call stacks are absolutely huge and debugging probably feels like a huge expedition. Spaghetti code gets its name not only because of the length of the noodle, but the number of noodles in the bowl. What are your criteria for breaking functionality out into its own method? Length of method is rarely the best way to decide. Do you use UML or anything to document your code? Are these methods usually private or public? Do your classes and methods make sense when you describe the functionality in a sentence? For instance, a Dog object has a Tail object property which has a Wag() method. So a dog has a tail than can wag.
My call stacks aren't huge because the smallest methods are usually very simple and don't call much else. It's probably hard to judge it without seeing it. What really stands out to me though is when methods are 500 lines long, or in some cases more than 1000 lines long. I don't use UML, to be honest, I've never considered using it. I always saw it as a way to communicate ideas to others and not a form of documentation. You could argue that my code is (often) documented by developer (unit) tests though. I usually break up the code based on whether it makes sense, and reads like a sentence. It certainly isn't broken up based purely on the number of lines. I try to follow most of the guidelines in 'Clean Code' by Bob Martin. This is a really good book IMO.
-
Member 4487083 wrote:
one or two lines
That's probably too short. How often are they called? From how many places? When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro. :-D
PIEBALDconsult wrote:
When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro.
In C# it will often get inlined by the JIT anyway so there shouldn't be any performance issues.
-
PIEBALDconsult wrote:
When I have a really short method that gets called frequently I reach for the C pre-processor and write a macro.
In C# it will often get inlined by the JIT anyway so there shouldn't be any performance issues.
Member 4487083 wrote:
will often get inlined
But it seems unpredictable.
-
My call stacks aren't huge because the smallest methods are usually very simple and don't call much else. It's probably hard to judge it without seeing it. What really stands out to me though is when methods are 500 lines long, or in some cases more than 1000 lines long. I don't use UML, to be honest, I've never considered using it. I always saw it as a way to communicate ideas to others and not a form of documentation. You could argue that my code is (often) documented by developer (unit) tests though. I usually break up the code based on whether it makes sense, and reads like a sentence. It certainly isn't broken up based purely on the number of lines. I try to follow most of the guidelines in 'Clean Code' by Bob Martin. This is a really good book IMO.
-
Member 4487083 wrote:
will often get inlined
But it seems unpredictable.
Does the performance difference matter? On the occassions where it doesn't get inlined I suspect that the performance difference won't matter in at least 95% of situations. There are other performance disadvantages of large methods though.
-
So your call stacks aren't long and your methods are 1 or 2 lines. Yet your code does the same thing as something with methods 500 to 1000 lines long? Either you have 250+ methods, or you aren't comparing code with equivalent complexity.
T M Gray wrote:
So your call stacks aren't long and your methods are 1 or 2 lines. Yet your code does the same thing as something with methods 500 to 1000 lines long? Either you have 250+ methods, or you aren't comparing code with equivalent complexity.
Well, there's a balance between the two really. A single 1000 line method probably isn't ideal, and 1000 single line methods probably wouldn't be ideal either. Is there a problem with writing 250+ methods though? If you have a complex problem then you may create a number of classes and methods for it. Putting 250+ methods in a single class probably isn't great, but if you have that much code then it can probably be split up into multiple classes. My call stack would be longer, but I wouldn't normally consider them to be too long. I generally don't see this to be an issue. It can also be useful when an exception is thrown and logged (or unhanlded). Exceptions give you the stack trace, and if an exception is thrown in a 500+ line method then it's likely to be more difficult pin point the problem than if it was a 10 line method. You are right about the complexity in some ways. However, almost all of the long methods I see can easily be broken down into smaller parts. Even breaking them into methods with 100 lines of code would make the code much more readable. Although I do write single line methods, a lot of code is more than a couple of lines long, but never 500+ lines.
-
T M Gray wrote:
So your call stacks aren't long and your methods are 1 or 2 lines. Yet your code does the same thing as something with methods 500 to 1000 lines long? Either you have 250+ methods, or you aren't comparing code with equivalent complexity.
Well, there's a balance between the two really. A single 1000 line method probably isn't ideal, and 1000 single line methods probably wouldn't be ideal either. Is there a problem with writing 250+ methods though? If you have a complex problem then you may create a number of classes and methods for it. Putting 250+ methods in a single class probably isn't great, but if you have that much code then it can probably be split up into multiple classes. My call stack would be longer, but I wouldn't normally consider them to be too long. I generally don't see this to be an issue. It can also be useful when an exception is thrown and logged (or unhanlded). Exceptions give you the stack trace, and if an exception is thrown in a 500+ line method then it's likely to be more difficult pin point the problem than if it was a 10 line method. You are right about the complexity in some ways. However, almost all of the long methods I see can easily be broken down into smaller parts. Even breaking them into methods with 100 lines of code would make the code much more readable. Although I do write single line methods, a lot of code is more than a couple of lines long, but never 500+ lines.
If you have 250+ methods then I'd say that you immediately violated Single Responsibility.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
If you have 250+ methods then I'd say that you immediately violated Single Responsibility.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
Pete O'Hanlon wrote:
If you have 250+ methods then I'd say that you immediately violated Single Responsibility
Agreed. SRP would be violated just as much if the same code was within a single method though.
-
Pete O'Hanlon wrote:
If you have 250+ methods then I'd say that you immediately violated Single Responsibility
Agreed. SRP would be violated just as much if the same code was within a single method though.
Indeed - the point I was trying to make was that the code should be better in other classes.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
Does the performance difference matter? On the occassions where it doesn't get inlined I suspect that the performance difference won't matter in at least 95% of situations. There are other performance disadvantages of large methods though.
Like what? (Just askin'.)
-
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.