Your longuest function!
-
I hate to say it, but... i agree with fat_boy. Much as i love disappearing for a few days and coming back with a nice little self-contained library, i still find myself interfacing with other people's code more often than not. And once you're doing that, you can either propagate their design mistakes throughout your app, or you can buckle down and write a proper wrapper, complete with message crackers, error code translators, and exception handlers. It's ugly by necessity, and having it all in one place is an advantage.
---- Scripts i’ve known... CPhog 1.7.1.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
I actually agree...but these are all special cases (I'm also thinking of the previous two replies), rather than the norm for most developers. My point being that if you had to maintain any non-trivial (my emphasis - message crackers are a different story) method of more than 100-200 lines you can all too easily find yourself misunderstanding the paths through the code. That leads to an increased risk of hard to find bugs appearing later as the code is maintained or enhanced. Cyclometic complexity is of course arguably a better all-purpose measure of the maintainability of a method - it will assign a low complexity to a long method with very simple control flow, and a far higher one to a shorter method with excessive nesting. If you can successfully balance complexity metrics with a code density/length/nesting you feel comfortable maintaining you are more likely to end up with code you can work with in the long term.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Who mentioned C? A non MFC app can have a defwindowproc in C++. Design has nothing to do with implementation, and in many cases huge switch statements are the best implementation.
Truth is the subjection of reality to an individuals perception
A long switch statement is likely to be very linear in flow, and therefore less of an issue than most methods. There are (as I pointed out in my reply below) a bit of a special case today. Run a cyclomatic complexity analysis on methods within your code and you'll see what I mean.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I actually agree...but these are all special cases (I'm also thinking of the previous two replies), rather than the norm for most developers. My point being that if you had to maintain any non-trivial (my emphasis - message crackers are a different story) method of more than 100-200 lines you can all too easily find yourself misunderstanding the paths through the code. That leads to an increased risk of hard to find bugs appearing later as the code is maintained or enhanced. Cyclometic complexity is of course arguably a better all-purpose measure of the maintainability of a method - it will assign a low complexity to a long method with very simple control flow, and a far higher one to a shorter method with excessive nesting. If you can successfully balance complexity metrics with a code density/length/nesting you feel comfortable maintaining you are more likely to end up with code you can work with in the long term.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote:
My point being that if you had to maintain any non-trivial [...] method of more than 100-200 lines you can all too easily find yourself misunderstanding the paths through the code.
No arguments there! :)
---- Scripts i’ve known... CPhog 1.7.1.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
A long switch statement is likely to be very linear in flow, and therefore less of an issue than most methods. There are (as I pointed out in my reply below) a bit of a special case today. Run a cyclomatic complexity analysis on methods within your code and you'll see what I mean.
Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
That is true, this switch statement handles about 10 cases, each one then looks at the state machine, which can be in one of 12 states. Inside some of these a lot of data needs pulling apart. However, I prefer to see the complexity all in one place with just two or three layers of nesting. One thing I really hate is pointless nesting where each layer really does very little work buit calls downm to a lower layer and so on. You can spend hours tracking downthe code that actually does something.
Truth is the subjection of reality to an individuals perception