![]() |
|
C++ basics part 1 - Printable Version +- Sinisterly (https://sinister.ly) +-- Forum: Coding (https://sinister.ly/Forum-Coding) +--- Forum: C, C++, & Obj-C (https://sinister.ly/Forum-C-C-Obj-C) +--- Thread: C++ basics part 1 (/Thread-C-basics-part-1) Pages:
1
2
|
RE: C++ basics part 1 - cxS - 09-19-2013 (09-19-2013, 03:54 AM)Cyanide and Cynicism Wrote: Because it looks gross. You read where I said it was preference correct? Other than that, all you did was move a "*/" to a new line, yours compared to his is no different. If you care about such minute detail in comments, as opposed to the quality or succinctness of the code itself, you are probably looking at programming the wrong way. RE: C++ basics part 1 - w00t - 09-19-2013 No, form is pretty important when you're working with a team of people. If your code is ugly to read, that means its less likely to be read, which tends to lead to bad things. DOX: // This function // will // return /* an array if * it succeeds */ // and a null // pointer // if it does // not Programmer 1: Ain't nobody goin' care bout dis, its just whitespace Programmer 2: Well fuck that shit, I'll just assume it errors if something goes wrong <0day effecting the entire world> Programmer 1: I clearly said it would return a null pointer! Programmer 2: Fuck you, gumby, why would I read that shit Very extreme example is extreme. RE: C++ basics part 1 - cxS - 09-20-2013 (09-19-2013, 05:47 AM)w00t Wrote: No, form is pretty important when you're working with a team of people. If your code is ugly to read, that means its less likely to be read, which tends to lead to bad things. I never said it wasn't, any good programmer knows form is important or consistency. This doesn't mean that everybody has to use the same form. Look at the difference in the comment "form" he posted compared to what OP posted, that much difference is insignificant. Even so, what is the most important to look at there is the width of the comments, nobody writes a comment with one or two words per line like that. Everything else is preference, as long as it's consistent because the programmer should then know what to look for by seeing other comments in the code. Nobody writes code the same way, so the important thing is consistency; any programmer reading your code won't get caught off guard. You too, missed the point of what I posted above (even though I thought it was pretty clear). It was also more directed at the changes he made to the existing comment format OP had been using. Most IDE's have good syntax highlighting anyways along with intellisense that more clearly indicates the intentions of the programmer. Code clarity is still important today, but it was most important back when IDE's were just no better than notepad. Also, OP never mixed comments like you did, so your extreme example was both not necessary and extremely irrelevant in my opinion. You didn't even mention what was wrong with the comments you had in your example (although implications could be easily made), and you never posted your suggestion on what comments should look like (your opinion). All of you posted the same old look OP did, in variation, while the main thing I see wrong is the width really: Code: // This
// is
// NOT
// efficient
// use
// of
// line spaceDepending on the font used, and the length of the words in a line, I would say anywhere from 15-20 words per line is much better. And linespace used to break out key parts of what the comment is trying to describe. I've even seen comments like this with double stars to keep everything vertically aligned. That is preference though, not any difference in clarity, which is the only important part about "form" as you describe it. Code: /*
** Text Text Text Text Text Text Text Text Text Text Text Text Text
** Text Text Text Text Text Text Text Text Text Text Text
** Text Text Text Text Text Text Text Text Text Text Text Text
** Text Text Text Text Text Text Text Text Text Text Text Text Text
** Text Text Text Text Text Text Text Text Text Text Text.
*/Some of the best programmers just use simple "//"s and some use the multi-line comments normally. RE: C++ basics part 1 - Phoenix2014 - 10-07-2013 Thanks for this I will be doing this later and let you know how I get one Rated thread 5 stars!
RE: C++ basics part 1 - TechSaavy - 10-07-2013 It's a nice guide I think this is the language ill choose to learn from now on ![]() A nice plus is that you explained the differences between int, double and float, as I never actually understood the guides that was written "formally". |