Programming standards...no flaming please!
-
leckey wrote:
I know...I know. It does interact with another 3rd party product that uses FORTRAN.
:omg:
Whats with the :omg: - FORTRAN is a *real* engineers language....it's actually pretty good for engineers who aren't really software people - the language is simple enough that they can write their code to do what they want...and then you can wrap the horrible Fortran in something else (Ada 95 in my case - don't ask). Of course, these days, they're more likely to design the thing in Simulink[^] and autocode it using Real Time Workshop[^]. WHich isn't necessarily any better for the software person trying to interface to their code...
-
led mike wrote:
Don Miguel's comment on Code Complete[^]: Priceless
Please explain what is good about that. You've posted this as being some high-quality post-of-the-year a few times, but I fail to see anything that stands out about it.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote:
I fail to see anything that stands out about it.
Sorry I guess you have no sense of humor. I sent the OP and Don's reply to as email to devs in my group and it kills them all. People have it pinned up to their walls along with various Dilbert strips. For me it is the funniest post so far in the Lounge (Category: Development Related) :-D
-
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.
leckey wrote:
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.
Thats is quite common for a generated parser.**
xacc.ide-0.2.0 preview - Now in 100% C# goodness
**
-
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 :: ^_^