|
Have you ever worked with someone who wrote "books" of comments?
A few lines of code -- preceeded by 10 or 15 lines of comments.
Regurally! I did. I did NOT like to get into his code! Everything
was explained (in DETAIL); but it was hard to follow the logic.
Now ... this was when I use Emacs and programmed in C on UNIX; but
even with todays VS7 IDE and the availablity of outlineing. One can
"over comment". I like pragma regions! I can write a long winded
explination why I did something and put it within a pragma region
close the region and all is well 
Personally -- I am somewhat long winded (can't you tell ) So my
comments abound. But! There are limits. A nice balance.
Consistancy of formating and consistancy in comments!
(By the by -- on spelling -- I am a poor speller. And the VS IDE
does not contain a spell checker. I have found that a little program
call "ClipMate" has an excellent spell checker. Just copy your comment
to the clipboard -- use ClipMate's spell checker and paste it back in.
Simple!)
WedgeSoft
|
|
|
|
|
Gammill wrote: And the VS IDE
does not contain a spell checker
Take a look at Spelly from WndTabs[^] Works well enough in VS6. Haven't tried it in VS2005.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
It works OK in VS 2003. Though I couldn't get it to work on my work PC. however, it was a machine used by several previous people so that may have been the problem. Not tried it in VS 2005. I also use TextPad's spell checker on the VS source files.
Kevin
|
|
|
|
|
Not interested. As I said -- ClipMate is great. It will not go
through all the code; picking out comments and spell check; but
those hunks I want checked are easily checked. And it works great
for things like this little note -- I'll Ctrl-A, Ctrl-C, Ctrl-Sh*t-C,
F7, and Ctrl-V and this little note has been checked. (Reads, like
a lot; but programmers should be good with accelerators, shouldn't they?)
WedgeSoft
|
|
|
|
|
Gammill wrote: Ctrl-sh*t-C
Did you spell check this post or did you intend to use a swear word?
|
|
|
|
|
 -- my bad -- "Ctrl-Shift"
WedgeSoft
|
|
|
|
|
Gammill wrote: Have you ever worked with someone who wrote "books" of comments?
A few lines of code -- preceeded by 10 or 15 lines of comments.
Regurally! I did. I did NOT like to get into his code! Everything
was explained (in DETAIL); but it was hard to follow the logic.
Back in college I kept getting notes from the TA saying "not enough comments" and got irritated at getting the same thing no matter what I tried (we're talking within reason here, headers, end of loop markers variables, etc.).
So I decided to get "unreasonable" and go "overboard". Out of an assignment with 230+ lines of code there were over 250 lines of comments. There was a header comment, that included full psuedo code of the entire procedure to follow as well as a full english description of the process, every line of code that matched the pseudo code had the matching line of pseudo-code repeated yet again. So there were 250+ additional lines of comments, plus most code lines had additional line comments on them....
It backfired, the TA wrote "good comments, could be expanded some more"  I was glad when that class was over.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Knew it! I read the first of your message in email, the rest on
log in to Code Project; but I just knew that was going to be the
punch line. I was luck. I did not graduate with a programming
degree. Learned my code on job and at home and from self sudsy.
Never had to go through that stuff.
WedgeSoft
|
|
|
|
|
I agree. I am a strong believer in comments, but there are coding styles in which comments containing little useful information are required. In most cases these only make code unreadable. Full documentation belongs in the manual. Only information pertaining to the code belongs in the code.
|
|
|
|
|
|
Let's see, when I format my code,
1. All indents are all tabs, or all whitespaces to be consistent.
2. No whitespaces or tabs at the end of any line.
3. The spacing between lines are always consistent. (e.g.: Skipping one line between methods.)
4. ... let's not get into spacing between tokens ...
ROFLOLMFAO
|
|
|
|
|
What would be really nice is if the code formatting dynamically adjusted and tracked the style of the particular user typing the code.
for example, if Joe Bob were typing and he preferred:
if( 1 == x ){
int a = x++ ;
}
Then his compadre Juan opened the file he would see:
if(1==x)
{
int a = x++;
}
and so on...
In my opinion, formatting is in the eyes of the beholder... the compiler doesn't care, just as long as it is syntactically correct.
Which means the file could be stored like this:
if(1==x){int a = x++;}
Just my 2 cents
|
|
|
|
|
Well, the compiler may not care, but things like diff tools and concurrent version systems will definitely care.
This is one of the massive advantages of the enforced formatting in Visual Studio - it makes code merging very very easy.
Yeah, the formatting is in the eyes of the beholder, until you start working with other people. Then it becomes necessary to stick to a standard.
While some people may get religious and say "how I format my code is my PERSONALITY!!!", well, there are lots of other things that make you unique. I should think that it would also be part of your personality if you cared whether or not other people could USE your code, too. (not speaking you personally; the global 'you')
|
|
|
|
|
Patrick Sears wrote: enforced formatting in Visual Studio
SAY WHAT?
Does Visual Studio 2005 enforce its own formatting rules?
Where's my sledge hammmer... 
Software Zen: delete this;
|
|
|
|
|
Actually, it does! I always like to leave one space after an opening '(' and before the closing ')' but VS always comes around and knocks it right off and even worse it actually adds one space before the opening '('! If you wrote this for example:
if( didItCheckOut )
It'd change it to this:
if (didItCheckOut)
But it does this only for C# and not for C++! Say, there's a subtle little signal in there: C++ folks know what they are doing and C# folks need to be told what they must do?! 
|
|
|
|
|
Things like that can be set in Tools|Options|Text Editor|...
But my formatting isn't as rigid as that. One of my peeves is that I can't tell VS that empty braces, brackets, and parentheses should be scrunched up;
f ( x ) ;
f() ;
byte[] a = new byte [ 4 ] ;
|
|
|
|
|
Sounds a bit like the language detection in word, it still sucks in version 2007 and it probably will in the next ten versions.
No, I like it the way it is..
WM.
What about weapons of mass-construction?
"You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
|
|
|
|
|
M i s t e r L i s t e r wrote: Which means the file could be stored like this:
if(1==x){int a = x++;}
Sounds good to me.
Plus, C# almost gets to the point where new-lines are unnecessary, I hope the next language reaches that point.
|
|
|
|
|
I always seem to end up working with code written by the three (3) people who "never bother doing any formatting?"
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
Same problem here, last week I had a piece of javascript without spaces, enters and any other proper formatting. Also all variable names were like a,b,c,d,x,y,z etc. That code was ready for the trashcan...
WM.
What about weapons of mass-construction?
"You can always try to smash it with a wrench to fix that. It might actually work" - WillemM
|
|
|
|
|
That is one I HATE. Had to work in someones code that
used single character var names. n, a, b, x, y etc.
In books and I will bet -- MOST code one reads
for (int i = 0; i < value; i++) {}
I never use "i" -- Always inx (or cnt or knt (etc))
for (int inx = 0; inx < value; inx++) {}
I NEVER use single character var names! Reason -- to hard
to search for. I can type! the difference between "i" and "inx"
is not that great and is so much easer to find my index if
I need to.
WedgeSoft
|
|
|
|
|
I hate it when people always capitalize their Html, CSS and other web tags. It really gets annoying, and it's really hard to read.
Trinity: Neo... nobody has ever done this before.
Neo: That's why it's going to work.
|
|
|
|
|
If I'm working on someone else's code then I will respect their formatting styles, but otherwise I am very strict with my formatting (close to the convention on idesign.net[^]). It is not just with code either, I always strictly format HTML/XML etc, and even normal text. Periods (full stops) in documentation (and this message) are always followed by two spaces, even though web browsers won't display them. Organisation of files within projects and members within classes also follows strictly applied formatting rules.
People who work with me usually claim I am pedantic, but to be honest I find it saves time in the long run by getting it right to start with: I've never had a situation where someone has needed to reformat my code to understand it.
|
|
|
|
|
David Wulff wrote: it saves time in the long run by getting it right to start with
So true of nearly everything...
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
David Wulff wrote: Periods (full stops) in documentation (and this message) are always followed by two spaces,
Phew, I'm not alone! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
