Programming standards...no flaming please!
-
I wasn't really sure if this belonged to a particular message board so please no flaming! I am wondering what others habits are when it comes to programming. I just inherited a huge VB.NET program. In one VB page it has over 10k lines of code. One function within that has about half those lines. Do you have a "limit" on how big/small a function/method/class should be before breaking it into smaller parts? We just used the analyzer on this thing and found one case statement has over 70 routes to go. So I'm hoping to clean this puppy up. BTW...heat index is currently at 109 degrees. Hope everyone else is staying cool.
"Things should be made as simple as possible, but no simpler." -- Albert Einstein My oppinion is that good developer should not ever directly think about the number of lines , number of classes, and other such things. He should develop a good, effective, usable classes. If some function, to accomplish it's function has to be long, let it be, but only while that function's function is a single strict logical unit. One should consider refactoring if he founds that a function does more than it should, not that it is just longer or shorter than ordinary.
-
I wasn't really sure if this belonged to a particular message board so please no flaming! I am wondering what others habits are when it comes to programming. I just inherited a huge VB.NET program. In one VB page it has over 10k lines of code. One function within that has about half those lines. Do you have a "limit" on how big/small a function/method/class should be before breaking it into smaller parts? We just used the analyzer on this thing and found one case statement has over 70 routes to go. So I'm hoping to clean this puppy up. BTW...heat index is currently at 109 degrees. Hope everyone else is staying cool.
You need this book: http://www.amazon.com/gp/product/0201485672/102-8688208-6140902?v=glance&n=283155 Desparately. I'm surprised no one has mentioned it yet. It is exactly what you need. Read it. Live it.
-
Ennis Ray Lynch, Jr. wrote:
Switch to c#
Amen brother! I hate VB.
Ennis Ray Lynch, Jr. wrote:
In business applications readability and maintainability and self-documentation is more important that the absolute fastest code [in most cases].
Like I said, it's ugly code. Not much commenting. Old code just commented out. And it is definately not that fast. If it were me I'd rewrite the entire thing.
-
Ennis Ray Lynch, Jr. wrote:
Switch to c#
Amen brother! I hate VB.
Ennis Ray Lynch, Jr. wrote:
In business applications readability and maintainability and self-documentation is more important that the absolute fastest code [in most cases].
Like I said, it's ugly code. Not much commenting. Old code just commented out. And it is definately not that fast. If it were me I'd rewrite the entire thing.
-
If you inherited it from someone within the company, go and smack them on the head. No code file should be 10k lines. Some functions may tend to be long, but they should be refactored where-ever possible, ideally I would say 30 lines is a max for a function. The book that covers all of this is called Code Complete. If you don't own it, buy it. While I found I knew most of what it was saying, I still found it exciting to see it all in written form, with logical explanations for the benefit of people like the clown who wrote the code you're now looking at. I am however cautious about refactoring existing code, do it if you can, but beware, lest you go crazy and spend heaps of time chasing an ideal that may introduce bugs in code that already works. Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
applications should be decomposed so that each method or function performs one action. at the top level of the application, the action may be "populate_database". this method would then call lower level methods to perform each of the actions to populate a database where each lower level method performs a single action. strict line limitations on methods or functions is arbitrary. although i do go by the "the method should fit on my screen" guide. as far as code file size, i don't believe there is a need to limit the file size arbitrarily. we limit a file to a single class. for some of our abstract base classes, the class is pretty big to cover all the base methods. working with methods or functions that perform multiple tasks is a nightmare. in a previous life, i had the truly unfortunate nightmare of having to work with a code file that was over 80000 (yes that's eighty thousand) lines long. one function within this file was over 12000 lines long. to add insult to injury, there were goto statements in the code (it was C code) that were used for regular program execution (not error recovery). to make it even worse (which is a challenge) there was a macro with a goto statement in the file!! decomposition of the application into single actions is the way to go. schleprock
-
Belated birthday wishes Rex. I should've remembered it, especially because my birthday is also July 18th :)
Regards Senthil _____________________________ My Blog | My Articles | WinMacro
Oh yeah! That's right! To you to. Do anything especially memorable? I went rollerblading then just did work as usual. Had a great barbecue later that day though. That was fun. Watched the kids get their fill of the kiddie pool and all that.:-D
When I'm joking people take me seriously.
When I'm serious they think I'm joking.
I'm left to conclude my life must be a complete joke. :sigh: :laugh: :cool: -
Ennis Ray Lynch, Jr. wrote:
Switch to c#
Amen brother! I hate VB.
Ennis Ray Lynch, Jr. wrote:
In business applications readability and maintainability and self-documentation is more important that the absolute fastest code [in most cases].
Like I said, it's ugly code. Not much commenting. Old code just commented out. And it is definately not that fast. If it were me I'd rewrite the entire thing.
-
Ennis Ray Lynch, Jr. wrote:
BTW, when I convert code bases I retype it.
OK - the code bases I have changed, it's been because I took a job and found the code was VB, and indicated I only did C#. There was really no option for me to hand type them. One I've been on for two years now, and I admit I still from time to time find code that I change to better reflect what C# can do. But after a day, I had a C# code base that worked fine.
Ennis Ray Lynch, Jr. wrote:
Fortunately with .NET you can mix languages
I thought you could only do that in ASP.NET, unless you mean mix languages between different dlls in the project, not within one project ? Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
You can't mix languages in the IDE within 1 project, but you can mix them if you are using commandline compile. The SDK Samples provide an example on how to do this. I find it sad people say I can't do VB, I can't do C#. It's programming. It's the language is a tool. If you are going to dig a hole, you usea shovel, if you are planting a flower in the garden you use a spade. If you are excavating, you use a backhoe.
-
You can't mix languages in the IDE within 1 project, but you can mix them if you are using commandline compile. The SDK Samples provide an example on how to do this. I find it sad people say I can't do VB, I can't do C#. It's programming. It's the language is a tool. If you are going to dig a hole, you usea shovel, if you are planting a flower in the garden you use a spade. If you are excavating, you use a backhoe.
Paul Farry wrote:
If you are going to dig a hole, you usea shovel, if you are planting a flower in the garden you use a spade. If you are excavating, you use a backhoe.
That's true, but C# and VB.NET are the same tool, except that VB can't do unsafe code. Beyond that, the analogy breaks down, there's no other place where one is the right tool over the other. Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Paul Farry wrote:
If you are going to dig a hole, you usea shovel, if you are planting a flower in the garden you use a spade. If you are excavating, you use a backhoe.
That's true, but C# and VB.NET are the same tool, except that VB can't do unsafe code. Beyond that, the analogy breaks down, there's no other place where one is the right tool over the other. Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
That's true, but C# and VB.NET are the same tool, except that VB can't do unsafe code. Beyond that, the analogy breaks down, there's no other place where one is the right tool over the other.
Nice re: the unsafe.. I'd never even looked at that. I meant in the context, of use what you need to given the job at hand. If you do VB use VB, if you do C# use that, but if you have code written one way that works (and it isn't flawed like stated in the message), use whatever you are comfortable with, because they are just tools.
-
Christian Graus wrote:
That's true, but C# and VB.NET are the same tool, except that VB can't do unsafe code. Beyond that, the analogy breaks down, there's no other place where one is the right tool over the other.
Nice re: the unsafe.. I'd never even looked at that. I meant in the context, of use what you need to given the job at hand. If you do VB use VB, if you do C# use that, but if you have code written one way that works (and it isn't flawed like stated in the message), use whatever you are comfortable with, because they are just tools.
I do a lot of image processing work, so unsafe is high on my radar, I realise for most people, it's not.
Paul Farry wrote:
If you do VB use VB, if you do C# use that, but if you have code written one way that works (and it isn't flawed like stated in the message), use whatever you are comfortable with, because they are just tools.
Oh, OK. I agree with that. I think I also said, moving the code from VB to C# won't fix it, and can introduce more problems. I've done it to take on big jobs, but I made clear to the client that I was doing it for my own preference, and they were free to look for someone comfortable in VB if they preferred. Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
I wasn't really sure if this belonged to a particular message board so please no flaming! I am wondering what others habits are when it comes to programming. I just inherited a huge VB.NET program. In one VB page it has over 10k lines of code. One function within that has about half those lines. Do you have a "limit" on how big/small a function/method/class should be before breaking it into smaller parts? We just used the analyzer on this thing and found one case statement has over 70 routes to go. So I'm hoping to clean this puppy up. BTW...heat index is currently at 109 degrees. Hope everyone else is staying cool.
-
Christian Graus wrote:
If you inherited it from someone within the company, go and smack them on the head.
Unfortunately, it's my BOSS. I will look at the book. I am hoping to persuade said boss to let me rewrite this evil thing in C#.
leckey wrote:
rewrite this evil thing in C#.
If it helps, I posted some performance measurements up here some time ago. VB.NET is about 3x slower than C#. So if anything you'll get a boost there. May help in swaying the BOSS. And I do feel for you. I took over as Tech Lead on a project that sounds very similar however the guy who wrote it quit a month ago. Every line was wrapped in a try catch block meaning that for each line of logic there was at least 5 lines of code. Turns out all he needed to do was check for null! Instead he wrote a try catch block! Break functionality into a separate C# project where you can and strip as much out of the VB code as possible. Good Luck!! It's hot down here in TX!!! ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
I wasn't really sure if this belonged to a particular message board so please no flaming! I am wondering what others habits are when it comes to programming. I just inherited a huge VB.NET program. In one VB page it has over 10k lines of code. One function within that has about half those lines. Do you have a "limit" on how big/small a function/method/class should be before breaking it into smaller parts? We just used the analyzer on this thing and found one case statement has over 70 routes to go. So I'm hoping to clean this puppy up. BTW...heat index is currently at 109 degrees. Hope everyone else is staying cool.
A 5K-line function? a case statement with 70 cases? Pardon me while I run screaming into the night! A colleague of mine used to call that sort of thing "Wallycode" after the Wally character in the US comic strip Dilbert. Wallycode is code that is comprehensible only to the person who wrote it, and even that person forgets how to read it after three months. Martin Fowler has a terrific book called "Refactoring", which discusses how to break monoliths like this into manageable, maintainable systems and subsystems. I'd recommend that book. I try to keep functions to less than fifty lines, with less than five parameters to the function, and only one return value (no out parameters). I'd have to disagree with the comments made earlier about VB vs. C#. Either language will do a great job, once the app has some architecture applied to it. David Veeneman www.veeneman.com
-
mcintyrg wrote:
I have to vote in favour of the C# movement. VB is for kids
I switched from C to C# (company orientations :) ) since 2003... Never wrote a line in VB nor VB.net (apart from some few macros in MS Office). And I can say that there is no huge difference between VB.net & C# :sigh:, (may be C-like syntax but it relies on the same framework :(( ) :: YOU make history :: ^_^
-
mcintyrg wrote:
I have to vote in favour of the C# movement. VB is for kids
I switched from C to C# (company orientations :) ) since 2003... Never wrote a line in VB nor VB.net (apart from some few macros in MS Office). And I can say that there is no huge difference between VB.net & C# :sigh:, (may be C-like syntax but it relies on the same framework :(( ) :: YOU make history :: ^_^
-
mcintyrg wrote:
I have to vote in favour of the C# movement. VB is for kids
I switched from C to C# (company orientations :) ) since 2003... Never wrote a line in VB nor VB.net (apart from some few macros in MS Office). And I can say that there is no huge difference between VB.net & C# :sigh:, (may be C-like syntax but it relies on the same framework :(( ) :: YOU make history :: ^_^
Yeah in truth there is no real difference, just the way you have to write the code. The kid's refererence was really just a jibe at the way you use 'Me' in replace of 'this' ;P I think C++ is where you can do the real shit !! Although C++.NET not sure; don't know about you guys but haven't really seen many jobs going in it.... Lots of words of wisdom...
-
I wasn't really sure if this belonged to a particular message board so please no flaming! I am wondering what others habits are when it comes to programming. I just inherited a huge VB.NET program. In one VB page it has over 10k lines of code. One function within that has about half those lines. Do you have a "limit" on how big/small a function/method/class should be before breaking it into smaller parts? We just used the analyzer on this thing and found one case statement has over 70 routes to go. So I'm hoping to clean this puppy up. BTW...heat index is currently at 109 degrees. Hope everyone else is staying cool.
I've just started working at a new place and bump into uncommented methods over 500 lines on a regular basis. And sometimes find methods over 1000 lines but 5000 lines, what a joke. It would have taken 20 minutes for the original develoer to refractor, instead it takes you an hour just to work out whats going on. Unmaintainable and expensive. I try by refractoring, to keep methods down to under 100 lines. Case statements with over 70 cases can make it difficult but still, the larger a method becomes, the more value there is in refractoring. Classes over 10,000 lines aren't uncommon. Sometimes that just happens to be the right place for the code. I set everything out in regions anyway, so size isn't that much of a problem. BTW just on the subject of VB v C#. Its not the language that decides if the code is elegant or not, its the programmer. I don't understand why so many C# programmers feel so insecure to rubbish VB all the time. I write mainly in C# and prefer it but VB is OK with me as well.
-
Ennis Ray Lynch, Jr. wrote:
Switch to c#
*grin* That may be an effective filter to increase the odds of people who write 5000 line functions never working on the code again, but beyond that I don't see how moving to C# is a good thing. I've done large VB -> C# moves, and there's always a lot of stuff the converters can't fix, or places where the code they write really sucks. One can remove the VisualBasic namespace without moving to C#, if you want to get rid of legacy garbage.
Ennis Ray Lynch, Jr. wrote:
add unit tests.
Adding unit tests to an existing project of any size is a pretty decent sort of task. Unit tests are best written during development, not after. Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog