Code for the weakest coder

[Markbnj]

How about cout? cerr? errno? stdout?
I'm not just bringing these up to be a smartass -- I really do think there are legitimate times to use globals. But they're very, very rare.

Fair questions. I very rarely use cout or cerr, and never the standard streams anymore. I could argue that the ones you mention are in place as a bridge, but in the end you're right: my statement was too sweeping. I'll amend it to "I haven't written code to generate a single byte of global data in nearly twenty years."

It's difficult in modern languages to even create global data in a way that mimics the situation back when I first learned what the term meant. Pretty much everything exists in a scope narrower than a truly global scope, and should.

Parting word: This post might make me seem pro-global if taken out of context. I am still firmly anti-global -- you can all breathe again.

I had no doubts, and was breathing the whole time.

 

[Red Squirrel]

I think the key to code, or even a complex system configuration, is documentation. Document everything that is out of the ordinary or not obvious. Since we're speaking about code, comments are vital. I work in an environment where they have tons of complex and weird systems, yet nobody ever documented anything. it's pure hell, and it's not even a skill thing. Even the most skilled IT tech coming here would be lost. It takes a long time to get the hang of where everything is. Same goes with code, especially if it's not commented.

 

[smack Down]

Originally posted by: degibson

Originally posted by: JACKDRUID
by using globals, you lose flexibiliity of having a temporary copy of data for data validation purposes.

I disagree on this one. Simply because a variable's primary home is global doesn't mean you can't explicitly make a copy of it for validation, or otherwise work on a local dataset and then publish to global state. Thats what happens under the cover in many cases anyway -- it is merely more explicit.

I will take single thread code for 1000 please.

std::cout, std::cerr, and std::cin are effectively constants. There is nothing wrong with having constants be public.

As for the abomination errno. It sucks even for single thread code and useless for multi-threaded code.

 

[smack Down]

Originally posted by: RedSquirrel
I think the key to code, or even a complex system configuration, is documentation. Document everything that is out of the ordinary or not obvious. Since we're speaking about code, comments are vital. I work in an environment where they have tons of complex and weird systems, yet nobody ever documented anything. it's pure hell, and it's not even a skill thing. Even the most skilled IT tech coming here would be lost. It takes a long time to get the hang of where everything is. Same goes with code, especially if it's not commented.

Comments are really overrated. Often spread around in 7 or 8 files (superclass header file, header file, superclass code, code, and 3 or 4 places calling that method). The chance of all 8 being the same and correct is zero.

 

[Red Squirrel]

Originally posted by: smack Down

Originally posted by: RedSquirrel
I think the key to code, or even a complex system configuration, is documentation. Document everything that is out of the ordinary or not obvious. Since we're speaking about code, comments are vital. I work in an environment where they have tons of complex and weird systems, yet nobody ever documented anything. it's pure hell, and it's not even a skill thing. Even the most skilled IT tech coming here would be lost. It takes a long time to get the hang of where everything is. Same goes with code, especially if it's not commented.

Comments are really overrated. Often spread around in 7 or 8 files (superclass header file, header file, superclass code, code, and 3 or 4 places calling that method). The chance of all 8 being the same and correct is zero.

Yeah that's the thing, need to follow a standard for the comments.

For example in my header file I put a description of what the class/function is for and how to use it, and I put a short 1 line comment on each function to say what it's for. That's it. On the actual source file is where I comment groups of code to explain what it does, if it's not clear.

I treat the header file as a source of documentation. Rather then document my whole program separately, I just put all the info in the code itself, so if I want to see the name of the class and spelling of functions etc it's all in one place with explaination on how to use it. More or less, the header is the user's manual while the source is the coder's manual.

 

[chronodekar]

Originally posted by: RedSquirrel
I treat the header file as a source of documentation. Rather then document my whole program separately, I just put all the info in the code itself, so if I want to see the name of the class and spelling of functions etc it's all in one place with explaination on how to use it. More or less, the header is the user's manual while the source is the coder's manual.

The thing I have with comments is convincing the rest of my team to take them seriously. We recently had a Linux-related project to do. Lack of documentation was (and still is) a common complaint. I tried to rectify the problem by including doxygen-style comments throughout the code. (At least the parts I understood)

Just last week, I found that a co-worker inserted a custom function UNDER my comments, but ABOVE the function I was commenting on !! :roll:

When I asked him about it later, he sleepily told me that he thought the comments were something of usual "junk" comments he finds scattered around Linux code... -sigh-

I'm an advocate of source-code documentation. But it only works if the entire team understands their importance.

I had no doubts, and was breathing the whole time.

me too. I've seen you around here too often to think of you (degibson) as a pro-global fan.

Comments are really overrated

Personally, I think it depends on the code/project. And most importantly, WHO is doing the commenting.

-cd

 

[degibson]

Originally posted by: smack Down
Comments are really overrated. Often spread around in 7 or 8 files (superclass header file, header file, superclass code, code, and 3 or 4 places calling that method). The chance of all 8 being the same and correct is zero.

This is unfortunately all too true. I am a fan of comments, but good comments are not a replacement for a firm understanding of the code. The comments can help at times (and hurt at others), but the only way to really understand is to read the code and try to change or improve it.

 

[Scooby Doo]

Besides, what you comment and what your code actually does can be subtly different.

 

[degibson]

Originally posted by: Scooby Doo
Besides, what you comment and what your code actually does can be subtly different.

Or not so subtly. Case in point, a recent discovery:

// Returns a count of errors
bool RPCErrorCount() const;

 

[chronodekar]

Originally posted by: degibson

Originally posted by: Scooby Doo
Besides, what you comment and what your code actually does can be subtly different.

Or not so subtly. Case in point, a recent discovery:

// Returns a count of errors
bool RPCErrorCount() const;

:shocked:

...



-cd

 

[DannyBoy]

Originally posted by: KB
Comments are easy to standardize on, write them often and be descriptive, don't write a comment that is obvious like:

function doSomething(){} //this function does something

I have never shied away from globals. They are usually given their own class and are named so it is obvious they are global.


I have never heard of "coding for the weakest coder", but based on its description I would never advocate it. How will the weakest coder learn from the strongest, if all the code is written so the weakest would understand it. I have always coded for the strongest developer and the weaker ones then learn how to write better code by reviewing or updating the section of the code the stronger developer wrote.

I generally comment all my code line by line explaining each step along the way. It adds very little overhead when you're working in a structured planned environment.

 

[Ken g6]

Originally posted by: degibson

Originally posted by: Scooby Doo
Besides, what you comment and what your code actually does can be subtly different.

Or not so subtly. Case in point, a recent discovery:

// Returns a count of errors
bool RPCErrorCount() const;

Reminds me of this gem of a comment, from here:

/* This function is BOOL but actually returns TRUE,
FALSE and -2 because I've no time to change it
to int */

But at least this clarifies that it's the code that's wrong.