Code Formatting - A reflection of Coding Level?
-
I disagree. The VC IDE does a fine job of formatting. Your complaints actually reduce down to you simply preferring a different style... but that's a religious debate that's been raging since the advent of computers. To address some of your complaints directly: > All variables at the top of the function, one variable per line. In C this is fine. In C++ this is a bad idea. Many declarations result in very expensive calls to constructors. If the flow of control dictates that a variable may not even be used declaring it at the top of the function results in unnecessary overhead. In C++ you should declare variables as close to first use as possible, and not before. > Variables other than counters named using Hungarian notation. An all together different religious debate. Hungarian notation in C++ serves very little purpose, and I've never seen it used consistently enough to be of any real help. Even the MS code (they were responsible for the advent of HN) uses HN inconsistently, at least partly due to legacy trivia (such as changes in the actual types when the switch was made from Win16 to Win32). I'm not going to try and convince you to change your preferences here, but there's a HUGE difference between poorly formatted code and code using a format different from yours. William E. Kempf
My previous message was poorly formatted itself. Things I find annoying about the VC IDE wizards include: Not separating wizard created functions and variables. Create a few variables and functions and see how they are laid out in the header file. Interleaving public, protected and private areas in the header file. Sticking the entire CAboutDlg class at the bottom of the app classes implementation file. Sticking the implementation of some class constructors in the header file. The list of my personal style preferences was just that - my personal style preferences. I don't expect the IDE to implement them, although it would be nice if MS followed the Hungarian notation conventions it suggests for others.
-
Me too Oz. I often drive my co-workers nuts by reminding them to go back over their code and make it clearer/better formatted/better commented...:rolleyes: Have you noticed that the people with the messiest code are the ones that are most likely to take exception when someone else reformats part of it? ;P Andy Metcalfe - Sonardyne International Ltd
(andy.metcalfe@lineone.net)
http://www.resorg.co.uk"I used to be a medieval re-enactor, but I'm (nearly) alright now..."
-
Is this only me and the people around me, or do you also find that cleanly formatted code is usually an indication of cleanly written code? I've been seeing more and more evidence that the experienced programmers take the time to allign and place each line of code, each variable definition, in it's neat little place. The novice and intermidiate programmers just stick code thier cursor happens to be, kind of like "this thing isn't thought out, so why bother making it pretty." I personally hate reading code with sloppy formatting, which makes it that much more frustrating. Anyone else experience this? -Oz --- Grab WndTabs from http://www.wndtabs.com to make your VC++ experience that much more comfortable...
Well I have noticed that the developers who contribute articles to this site have always presented cleanly formatted code. Since we don't see poorly presented code here one must assume that those who don't care about the presentation of their work never have anything worthy to offer to the rest of us. One of my worst habits when taking over existing code is that I always feel the need to reformat and tidy up its appearance before I can *really* get in and read/comprehend what the code is saying. Poorly presented code is simply harder to read. :eek: Over the years as I have worked for many different clients I have always been presented with a new set of 'rules' on code formatting, usually called a 'style guide'. Since everybodys idea of style tends to be significantly different I now have a very inconsistant looking code base, which really bugs me. I would like to see the 'gurus' define THE STYLE GUIDE which I would adopt religiously, and preach it to the unconverted. I don't mind changing the style I write too, but I do hate having to change it every week. X| Regards, Robert Dickenson.
-
Is this only me and the people around me, or do you also find that cleanly formatted code is usually an indication of cleanly written code? I've been seeing more and more evidence that the experienced programmers take the time to allign and place each line of code, each variable definition, in it's neat little place. The novice and intermidiate programmers just stick code thier cursor happens to be, kind of like "this thing isn't thought out, so why bother making it pretty." I personally hate reading code with sloppy formatting, which makes it that much more frustrating. Anyone else experience this? -Oz --- Grab WndTabs from http://www.wndtabs.com to make your VC++ experience that much more comfortable...
Some of my pet peeves are not coding in such a way as to help yourself/others when debugging. Simple stuff like the following:
void *someFunc() { return aValue;)
This is really badly written. If put a break point on it you can't see the the value of 'aValue'. Why? Becasue the stack frame is not set up. To set the stack frame up you have to switch to assembly view, and step until the stack frame has been set up. Slow, cumbersome, thoughtless. Writing it...
void *someFunc()
{
return aValue;
)solves this problem. Its a trivial fix which saves an enormous amount of time. Also not declaring constructors and destructors even if they are not used. These are often great places to put breakpoints. Likewise they should be written so that the code for them is not inline. So that editing them to put debugging code in doesn't touch the header file and cause a huge rebuild. Again trivial stuff, but a lot of people just don't get it, :-(. End Rant Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
-
Some of my pet peeves are not coding in such a way as to help yourself/others when debugging. Simple stuff like the following:
void *someFunc() { return aValue;)
This is really badly written. If put a break point on it you can't see the the value of 'aValue'. Why? Becasue the stack frame is not set up. To set the stack frame up you have to switch to assembly view, and step until the stack frame has been set up. Slow, cumbersome, thoughtless. Writing it...
void *someFunc()
{
return aValue;
)solves this problem. Its a trivial fix which saves an enormous amount of time. Also not declaring constructors and destructors even if they are not used. These are often great places to put breakpoints. Likewise they should be written so that the code for them is not inline. So that editing them to put debugging code in doesn't touch the header file and cause a huge rebuild. Again trivial stuff, but a lot of people just don't get it, :-(. End Rant Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
You've touched on one of my bete-noirs. If a function *isn't used* then it shouldn't exist. If the default constructor/destructor etc is correct for a class, then you shouldn't rewrite it. When I'm reading your code, if I come across a replacement for one of the defaults, which provides exactly default behaviour, I'm left wondering whether you intended non-default behaviour and made a mistake, don't understand the default behaviour, or are mindlessly following silly coding rules. If later I find a constructor that differs trivially from default behaviour, I now have no idea whether you intended default behaviour, or not. Furthermore I would suggest that if someone writes code where setting breakpoints in default constructors/destructors is essential to debug the code, then you have far more serious problems than code layout. Dan
-
Is this only me and the people around me, or do you also find that cleanly formatted code is usually an indication of cleanly written code? I've been seeing more and more evidence that the experienced programmers take the time to allign and place each line of code, each variable definition, in it's neat little place. The novice and intermidiate programmers just stick code thier cursor happens to be, kind of like "this thing isn't thought out, so why bother making it pretty." I personally hate reading code with sloppy formatting, which makes it that much more frustrating. Anyone else experience this? -Oz --- Grab WndTabs from http://www.wndtabs.com to make your VC++ experience that much more comfortable...
EXACTLY!!! if you code within a group of people and they can't read your code, then you are a drag on the group's efficiency and productivity. cleanly formatted code is the MINIMUM of professionalism. anything less is unprofessional hack code that needs work. my code standards for people i mentor or work with include large amounts of formatting and naming. my standards aren't nuts or 100% anal about "put a space there", but if you don't take the time to learn the easy habits of code formatting, what other more iportant code habits have you slacked off on? -John
-
Is this only me and the people around me, or do you also find that cleanly formatted code is usually an indication of cleanly written code? I've been seeing more and more evidence that the experienced programmers take the time to allign and place each line of code, each variable definition, in it's neat little place. The novice and intermidiate programmers just stick code thier cursor happens to be, kind of like "this thing isn't thought out, so why bother making it pretty." I personally hate reading code with sloppy formatting, which makes it that much more frustrating. Anyone else experience this? -Oz --- Grab WndTabs from http://www.wndtabs.com to make your VC++ experience that much more comfortable...
I disagree. The reason is that I've been on the reading end of many programmers code, usually in debugging. The ones that are obsessive-compulsive about prettifing their code tend to spend more brain power on formatting the code than actually programming, and tend to make STUPID mistakes. Although it is indeed easier to fix these bugs because of their style, I don't find that neat programming leads to less bugs or better code. Also, sloppy code doesn't mean worse code, since it can be a reflection of many things. For instance, they may not have the time to make it pretty. I know one employer that thought that if the code looked too good, it meant you had too much time on your hands. Finally, some people do have a consistent style, that is easy for them to read and understand, but not so easy for other programmers to read and understand. They write better code in their own way, and would produce worse code if forced to do it in a different way.
-
I disagree. The reason is that I've been on the reading end of many programmers code, usually in debugging. The ones that are obsessive-compulsive about prettifing their code tend to spend more brain power on formatting the code than actually programming, and tend to make STUPID mistakes. Although it is indeed easier to fix these bugs because of their style, I don't find that neat programming leads to less bugs or better code. Also, sloppy code doesn't mean worse code, since it can be a reflection of many things. For instance, they may not have the time to make it pretty. I know one employer that thought that if the code looked too good, it meant you had too much time on your hands. Finally, some people do have a consistent style, that is easy for them to read and understand, but not so easy for other programmers to read and understand. They write better code in their own way, and would produce worse code if forced to do it in a different way.
I think the only thing this thread proves is that generalization is always a bad thing. That said.... sloppy code indicates sloppy thinking. Everyone makes mistakes. Consider: - If you don't have time to make the code neat, you probably don't have time to make it work right. Doing code in a hurry is a recipe for error. - Making bugs easier to find and fix results in fewer bugs. How can anyone argue that point?
-
I think the only thing this thread proves is that generalization is always a bad thing. That said.... sloppy code indicates sloppy thinking. Everyone makes mistakes. Consider: - If you don't have time to make the code neat, you probably don't have time to make it work right. Doing code in a hurry is a recipe for error. - Making bugs easier to find and fix results in fewer bugs. How can anyone argue that point?
I disagree completely. "neat" is a subjective quality. If someone has to make their code conform to some "neatness" standard than is different from their own, that obviously takes a lot more time than if they use their own. Further, have you never heard of the term "conservation of energy"? I knew this guy with a desk piled high with stuff that nobody could find anything in, yet if you asked him, he knew where everything was and could find it in an instant. He didn't waste time organizing and quantifying, but rather simply remembered where everything was, conserving energy which he used to great effect elsewhere.
-
You've touched on one of my bete-noirs. If a function *isn't used* then it shouldn't exist. If the default constructor/destructor etc is correct for a class, then you shouldn't rewrite it. When I'm reading your code, if I come across a replacement for one of the defaults, which provides exactly default behaviour, I'm left wondering whether you intended non-default behaviour and made a mistake, don't understand the default behaviour, or are mindlessly following silly coding rules. If later I find a constructor that differs trivially from default behaviour, I now have no idea whether you intended default behaviour, or not. Furthermore I would suggest that if someone writes code where setting breakpoints in default constructors/destructors is essential to debug the code, then you have far more serious problems than code layout. Dan
Furthermore I would suggest that if someone writes code where setting breakpoints in default constructors/destructors is essential to debug the code, then you have far more serious problems than code layout. Indeed. Code layout is part of a larger job of thinking about minimising the cost of code maintenance. If adding a destructor or default constructor to a class definition is going to cause a large rebuild (lets say most of the files in most of the 50+ DLLs of 2 million lines of code - and yes I am working on code where a few files are sadly this important - (*)), then having that constructor/destructor always defined (even if #ifdef _DEBUG conditionally compiled) is a major bonus as I don't have to wait a few hours whilst it builds. I guess I got slightly off topic, but it is these trivial things that do matter. Default constructors/destructors that are supplied by the compiler are identical to empty constructors/destructors, so if I found them in someones code I'd assume they are there for a reason, not because of a mistake. I guess we have different attitudes to /expectations of the rest of the team we work with. Besides a decent comment with each would put your mind at rest in any case. (*) One part of my gig with these people is to track down resource and performance problems that the rest of the team are too busy to look at. As a result I'm often dumped into code I've never seen before. In those cases constructors and destructors and lifetimes of said objects are often a great help in determining at what point something didn't go as planned. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.