What is Digg?86 Comments
- Vampyric, on 10/12/2007, -0/+6I don't necessarily agree with every point the author makes, but the supposed know-it-alls on here calling this horrific are laughable. You either did not read his reasoning or did not follow it.
For instance, in 1) his point is that it is not necessary to have a complete design to begin coding. This is actually an axiom of extreme programming. If you have complete tests and refactor, you design interatively instead of up front. You have condfidence in refeactoring precisely because you have complete tests.
Also, the point about unsigned int vs signed int seemed to go over your heads...the point is that in C/C++ you are not actually preventing bugs but trading one form of bug for another because there is no runtime detection of overflow. If you have unsigned int foo, if someone does foo = -1, it didn't help you any. There is no detection of it. You just wind up with foo = 0xffffffff which is just as wrong. I don't necessarily agree overall, but that people would react so derisvely too it shows that you simply don't understand.
Just generally i see a lot of snide remarks but no counterarguments. The irony of digg comments is that whenever a non-technical article is posted people complain that digg is for technical stuff, but when something technical is actually posted, the level of discourse is terrible. Slashdot may not be the be all and end all of technical user discussion, but holy cow, it makes digg look like dogcrap in comparison. A better moderation system is sorely needed.
- moron, on 10/12/2007, -1/+7Some of the worst suggestions by the author ever. Seriously, it sounds like someone who has never worked on a large project or had to create something that was going to be maintained for years. Some things he mentions are OK, but many are just outright flawed.
- oluckboy, on 10/12/2007, -0/+4As pirate Barbossa said....
"... the Code is more what you'd call "guidelines" than actual rules. Welcome aboard the Black Pearl, Miss Turner!"
Listen to the pirate and skip the article. - gcauthon, on 10/12/2007, -0/+4This is retarded.
10: Use exceptions for handling exceptional situations. It's a way for the compiler to optimize the code by indicating "this branch is hardly ever taken".
9: Declare unsigned parameters as a way of self-documenting that you only expect a positive number to be passed.
8: This is just a way to teach OO to beginners. Nobody actually expects you to have classes like Cat and Dog that extend Animal.
7: If you waste time reformatting someone's code then it is difficult to see if you actually made any worthwhile changes. Reformatting the way YOU like makes it a reall PITA for someone to track your changes.
6: I've never heard this one. I've been programming for a long time and I've never heard anyone say "write LOTS of comments".
5: I'm confused. Are you for or against public fields?
4: . . . ok I'm bored of this. - CaughtThinking, on 10/12/2007, -0/+3"though it seems most of the deep hierarchy people have moved to Java and C#, leaving the C++ community to evolve in a direction that I think is more promising."
Actually concrete inheritance is frowned upon by any programmer that knows squat about OO programming. As for the Singleton, there's a whole religion dedicated to scoffing at that pattern know, but again, it's by people who didn't know squat about structure and over-singletonned everything. Maybe they should revisit the concept of a static vs. global vs. necessarily unique.
Maybe one day he'll enlighten us with a blog about how Ruby on Rails solves the Java problem too. - rubicante, on 10/12/2007, -0/+2I totally agree with a couple of the things he says - as unpopular as they are. People just like to reiterate "good programming techniques" because it reinforces their ego without actually assessing whether or not that technique has actually saved them time and/or made their project more successful.
- jackl, on 10/12/2007, -0/+2Wow. Do we have a lot of fundamentalist programmers here, or what? Time to switch to decaf, folks.
First of all, most of you who flamed this article need to learn the difference between someone saying "never" and someone saying "as a rule of thumb, don't".
For instance, the Singleton pattern. Is the Singleton pattern unnecessary in most of the code where it's used? Yes. I've seen programmers (including, unfortunately, myself) throw in SIngleton's without really thinking about why you should need that "global" information. A good design, in many cases, shouldn't have such global data, which is just what he was saying, IMHO.
As for the "unsigned" thing, yes, he does say he doesn't understand the use in size_t. So what? He's also completely right that setting a data value as "unsigned" doesn't really buy you any kind of checking, which is what a lot of newbie programmers think. Yes, it's necessary when you're, for instance, addressing memory or file sizes. But, and here's the point, it doesn't buy you *anything* the rest of the time. That's his point.
And, again, with the accessors, as one of you pointed out, there are cases where you need accessors, e.g. lazy initialization. Again, he's not saying "never use accessors" but rather "don't overuse them". I've seen much code where the programmer seems to think that he's encapsulating the class properly by making all the data members private, but then he goes and adds public accessors for every data member, completely destroying encapsulation. Often, the need for accessors indicates too much coupling between the classes, which is a design flaw. It's one of those little alarms that experienced programmers listen to (okay, not always, but you get my point), and that newbie programmers never, ever hear.
So, people, please, cut the guy some slack, here. - ezweave, on 10/12/2007, -0/+2Some of these things are true:
Exceptions are a must if you are coding something for someone else to use later (and you know this: i.e. open source projects, etc)... it can be hard to find runtime NPEs (or NREs depending on language).
Don't comment obvious things. (i = 0; //Now, I initialize 'i' to 0)
Singletons are useful.
Others are a bit dubious: design is important, corner cases might be needed... TODO lists don't always work, coding standards are vital for big projects... take some SE QA courses to learn why...
It's ok, I don't know how this is authoritative. Besides, I am not going to tell some CS100 student to do half of these things. Not when they can't tell the difference between "long" and "Long"... haha. - kish, on 10/12/2007, -0/+2Wow, no digg, this is terrible.
I haven't read past #9. The point about "use exceptions" followed by the point about "don't use unsigned because STL does and wraps values rather than indicating an error" makes ZERO sense. If that's how STL does it, then either STL should throw an error on an overflow or the user should check the bounds. That's why implementers make the behavior clear in the exception cases, so you know how they expect you to handle them.
As egbert says, the author obviously doesn't understand why unsigned is used. - Dangerman, on 10/12/2007, -0/+2Wow, I read most of his points and thought "Why is everyone disagreeing with him, most of these are decent?", it was at that point I realized that he was saying NOT to do these things.
This kid is an amateur, my ten year old writes better code. - astrosmash, on 10/12/2007, -0/+2Ha ha ha. If the digg peanut gallery thinks it's wrong, it must be right.
Let's look at the list from the bottom up:
1, 2, and 3: The most valuable advice in the list, anyone who wants to be a good coder and designer should read those a few times. Design before code is the obvious and naive dogma. Requirements and expectations will change after you begin coding, never before, regardless of how much time you spend in a design phase. Coding is understanding. Use prototypes to solidify the requirements and use the process of coding to solidify the design. We're in the age of RAD, after all.
4: Globals are bad. Wrapping them in the singleton pattern doesn't necessarily make them any better. Overuse of singletons may indicate a design problem.
5: Public fields are bad. Wrapping them in accessors doesn't necessarily make them any better. Exposing many fields in a class may indicate a design problem.
6: Prefer self-documenting code rather than comments.
7: Coding standards don't make up for poor programming. Good, experienced programmers always get the fundamentals right, regardless of any particular coding standards: meaningful variable names and organization; see point 6.
8: Classes don't have to correspond to objects in your domain model. Sometimes it's easy to forget this.
9: Unsigned integers don't necessarily provide real protection. "If you're stretching your code so far as to require the size gained by that one bit, you are probably in the danger zone of introducing errors of more serious kinds."
10: Use exceptions.
That list looks pretty reasonable to me, but I guess there's still no shortage of crappy programmers out there. - longman2g, on 10/12/2007, -0/+1the number 1 thing he says which is bad, design before coding, is a very easy thing to do, and save you a lot of time. Yes, you might spend a few days laying out the entire design of the program, and you probably will make some mistakes, but it is much easier to catch exactly what those mistakes are when you can see the program as whole right in front of you. If you get the hardest part out of the way in the beginning, then all you have to do is go through and write the code, instead of designing and redesigning it multiple times.
- Archimboldo, on 10/12/2007, -0/+1Crappy advice. No digg.
- TokenUser, on 10/12/2007, -2/+3No digg for really crappy advice.
- arnett, on 10/12/2007, -0/+1All of these ideas are counterintuitive. Most are counterintuitive because they are simply incorrect.
- AarronT123, on 10/12/2007, -0/+1Terrible article!
- egbert, on 10/12/2007, -1/+2I stopped reading at number 9 (the second one). The author obviously does not understand why size_t has to be unsigned.
- cecil_t, on 10/12/2007, -1/+2I digg it. I agree with about half of what he says, and as he said these are things that have to be learned for yourself from experience. It sounds like all you no-digg'ers are fresh out of school or work for a very large company who just drops in junior level programmers to write code that has already been designed by a software architect. His advice seems to be oriented to experienced programmers who work in smaller development teams.
- Otto, on 10/12/2007, -0/+1Yeesh. For those who don't know, size_t is unsigned for two very good reasons:
a) A negative size doesn't make any sense whatsoever, and
b) Memory addressing is unsigned as well, because memory starts at zero and goes up from there.
You're a program. You have this virtual address space which is 4 gig long. You know the address of some variable in memory, and it happens to be at about the middle of that address space. You also know the size of that variable. If the size and the address are both unsigned, then you can add them and get the address following that variable with no hassles.
But if the address is unsigned and the size is signed, then you can't add them at all. You'll have to convert one of them to the other in order to do that addition. And regardless of which one you convert, you could lose information. Signed->Unsigned doesn't cover negatives (even though it doesn't matter this particular case), and unsigned to signed could lose the top half of the space (and since you have 4 gig of virtual memory, this is easily a bad thing).
Having size_t as an unsigned ensures that you're using the same mapping for your sizes as you are for your addressing. Or, at least, that you can convert one of them without loss of information (if size is 32bit and your use 64bit addressing, you can promote the size to 64bit and guarantee no loss of information).
Although having a signed size will sometimes work, sometimes it won't. And when it doesn't, your program goes off into lalaland because you hosed some address pointer.
The rest of the article is similarly stupid. No digg. - usertwelv, on 10/12/2007, -0/+1No digg because I'm such a 133t haX0r that I can't bother to come up with any actual logic to dispute the author's arguments.
- Philoushka, on 10/12/2007, -0/+1I am not sure if I am not digging this because the article is so smart-ass, whether the author is so full of himself, or whether this author is so tongue-in-cheek that my sarcasm meter is broken.
Either way, no digg.
I do agree on the part about putting the author name, date, changed etc in the comments above a method. True, it does belong in the source code control mechanism WHEN THERE ACTUALLY IS ONE. :) For websites, sometimes this just does not happen. - simplisticton, on 10/12/2007, -0/+1It's pretty obvious that the negative commenters either didn't read the actual arguments or didn't understand what they read. Or they're just PHP or Java (ahem) "programmers" and don't know any better.
- egbert, on 10/12/2007, -0/+1There are many reasons for size_t. One of them being addressing more than 2G of memory on a 32-bit machine.
- SkipDaRoo, on 10/12/2007, -0/+1All the double negatives hurt my head
- Vampyric, on 10/12/2007, -0/+1note that 90% of the negative comments can't string together a sentence about why its such bad advice. I'd say just about every one of his points are debatable, but nothing is totally unreasonable as he argues his points farily well. Digg users, on the other hand, do not aquit themselves very well as usual. It's quite pathetic really.
- reubix, on 10/12/2007, -1/+1groupthink fools.
- Ninjamonk, on 10/12/2007, -0/+0// No Comments My ass
this guy has not worked with some of the people I have worked with.
Hands up how many people have rewritten someone elses ***** code that had no comments. - miletwo, on 10/12/2007, -0/+0Horrible advice. The #1 (this genius put that at the bottom) is "don't design before you build." Try telling that to an auto manufacturer. Programming is the same way. You may not need to design to the function level, but an architectural and procedural overview of your task is imperative to accomplishing the outcome.
no digg - SnakeO, on 10/12/2007, -0/+0article.sucks = true;
- binarypower, on 10/12/2007, -0/+0Seems like a gripe/bitch/showoff post No Digg!
- sshack, on 10/12/2007, -1/+1What a horrible article. This guy knows absolutely nothing about the real world.
and jesus, he doesn't know why size_t is unsigned, yet he thinks he has the authority to tell people not to use it?
Guy, go get yourself a degree and spend another 10 years in the industry (not doing ***** webmonkey crap) then you might be able to come up with a list of 2 things not to do. - renegadetempest, on 10/12/2007, -0/+0Wow. There are some completely flawed ideas in this piece. While I believe there are very few tried and true maxims in building systems (and in life for that matter), I think there are much better ways of building. Again, there are reasons people reiterate these guidelines.
No Digg. - inactive, on 10/12/2007, -0/+0It's interesting to see another person's approach to pogramming, but I disagree with some points, particularly number one! You cannot approach a large scale project by coding first and asking questions later. Maybe if it's a personal project, but you'll get laughed at when you finally get a job.
- chesterjosiah, on 10/12/2007, -0/+0There's so much negative feedback, I can't tell if this guy is saying not to follow the advice in the article, or not to not follow the advice in the article. It's hard to believe that a guy could be so disagreed with!
- LewsTherin, on 10/12/2007, -0/+0The headline is correct. None of the advice in the article should be followed.
- architectzero, on 10/12/2007, -0/+0advice from a developer still in training pants
no digg - cstmoore, on 10/12/2007, -0/+0Craptacular. No digg
- WaterDragon, on 10/12/2007, -0/+0I agree with the second part of the first thing, but not the third part of the fourth thing, ...and I think the fifth thing is the same as the seventh thing, an is totally suspicious! The other things are all arbitrary and capricious.
Can't we go back to science now? - xafan, on 10/12/2007, -0/+0This article is retarded and its a blog post. Who the ***** in their right mind tell teams not pick a standard format for their coding?
No digg. - exick, on 10/12/2007, -0/+0"Why on earth you would clutter the code with information that so obviously belongs in the version control system is just beyond me."
Because, in the real world, the people who have access to the version control system's information are CM and the coders when they're coding. Having a header show up between two versions makes differences easy to see and is especially useful when tracking changes with bug/trouble reports. - TokenUser, on 10/12/2007, -0/+0^^^ your style sucks. If you had planned this out, you could have written:
if (article.sucks) Console.WriteLine("No Digg") ; // Still no digg.
But, the design should have been obvious. Test for the extra case is pointless, why not just code:
Console.WriteLine("No Digg") ; // because that would be obvious - F1R3, on 10/12/2007, -0/+0I prettymuch agree with everyone else.
You need some kind of coding standard, though I'm not sure that bracket placement is exactly what people define as a coding standard.. that was a weak example.
I understand what he is saying about the comments, basically if you need comments you might need to instead go back and make your code more self explanitory.. but honestly.. I don't see the harm in commenting every single thing i do, even the most basic... because you never know what someone might need to know... the code always looks a lot more clear when your writing it then when you come back to it or you have to look at someone elses. Really helps with debugging too, if you put what you INTEND for something to do in there, someone else can easily just check to see if the comments match what your doing.
The rest of these are either badly labeled and or commen sense... like the input/output one.... duh.. you have to anticipate the input to some degree, so ofcourse it helps to limit it, and then handle what you have left over correctly.. who can't figure this out?
The thing about methods(functions) to access private variables is in most beginning programming books.. sheesh..
Crapola. - Cossins, on 10/12/2007, -0/+0Haha, this "debate" is precious reading! All flames from the "no digg"-camp. It seems the people who are actually too busy to post comments liked it, I'm guessing they're the ones who digged it in the first place.
Come on guys, you could at least put up a debate and not just flame... That's so childish. Good thing digg also lets you rate comments!
- Simon - lunarship, on 10/12/2007, -0/+0Some of this seems to come straight out of "The Mythical Man Month". And some out of the kvikkalkul design manual :-)
Overall, interesting read, whether you agree with it or not (actually, I think the points he's making are more subtle than "don't do this, ever", but there you go...)
digg for entertaining reading - wuleidando, on 10/12/2007, -0/+0somewhat force, but interesting
- mixd, on 10/12/2007, -0/+0This is funny - I was coming here to bash this article for all the same exact reasons everyone else already has. Saved me some typing.
- csrster, on 10/12/2007, -0/+0I have a lot of time for this articles. Most of these ideas are shibboleths for
newbie programmers and bugbears for the slightly more experienced. Perhaps it would have been more accurate if he had titled it "Ten Rules To Know When To Break", but he was obviously trying to be more provocative.
Personally I would have put number five as number one. Too many accessors is a sign of bad design. - bjoernz, on 10/12/2007, -0/+0about this "unsigned" variable stuff:
consider the following code:
int Example(char *str, int size)
{
char buf[80]
if (size < sizeof(buf))
{
strncpy(buf, str, size);
}
}
as you can see the size is signed, an attacker could maybe insert a -1 in there somehow, which is smaller than the size of the buffer (since the buffer has a positive size), but strncpy takes an unsigned int as the third parameter, so -1 is converted to 2^32-1...
"integer overruns" are said to be the new "buffer overruns" - Eccles, on 10/12/2007, -0/+0The core problem with size_t is that it isn't a number (no computer "number" is), it's a fancy bit pattern. You can't reliably test for overflow because there's no way to know, ditto underflow. Ok, a lot of the time overflow is a value larger than the max possible (-1 maps to LONG_MAX or the like), but if you did a multiply or added two large values, you might quietly get a wrong value. Ideally size_t have a max value far larger than the problem domain, or you would have some way to trap overflow or underflow.
- tackle, on 10/12/2007, -0/+0Horrible article. Obviously the author has never worked in a project that involves more than 1 person. And, I wonder why this article has 500+ diggs. Articles like these make me wish that there was a "no digg" button. I'm pretty sure this article would have got more "No diggs".
-
Show 51 - 84 of 84 discussions
Check out the new & improved 
© Digg Inc. 2009
— Content created and posted by Digg users is