What is Digg?Sponsored by Dragon Age: Origins
Join the Dragon Age: Origins development team on Facebook view!
facebook.com/DragonAgeOrigins - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
63 Comments
- locnguyen, on 10/12/2007, -1/+31Once you graduate and get a job in the real world, you'll find your "education" was a bit of a rip off.
- inactive, on 10/12/2007, -0/+18Frankly, this is a pretty bad article. These aren't habits of highly profitable software developers, these are "tips on how to write robust object-oriented programs." While learning to do that is good for most developers (i.e. the masses of programmers working on application-level Java/C++ programming), it really isn't describing the fundamental habits of which software developers are the most profitable.
Instead, I would say that habits of highly profitable software developers are far more general, rather than being so precisely tactical, something along the lines of:
- Creates readable and well-documented code, which saves time for future developers
- Effectively re-uses existing components or libraries
- Versed in a variety of powerful tools (rather than one) so that they can always pick the most efficient ones for the job
- Communicates effectively with technical and non-technical people - kevinyoder, on 10/12/2007, -0/+13@ahawks
Not a misconception. It actually has been shown to elevate nueral activity in the brain, and increase concentration.
http://www.xs4all.nl/~4david/caffeine.html
http://www.springerlink.com/content/6mnudkdx87n9c041/ - greyghost487, on 10/12/2007, -4/+16They forgot large stockpile of caffeinated beverages
Digg+ - roleary, on 10/12/2007, -2/+14Some basics in there... but pretty good advice for the most part. Except for this... I mean I'm all for explanatory method names, but come on!
testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername() - morphie, on 10/12/2007, -1/+13Habit 2 is just bull. It states:
"Long and descriptive method names help developer teams quickly understand the purpose and function of their software."
And then says that "testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername()" is a good descriptive function name. Well, I am a highly profitable software engineer myself and I want short simple method-names. I use Doxygen for descriptive texts. Not the method-name itself.
Every time I saw long method names or database-table names, the software wasn't readable and therefor bad maintenance was the consequence. :) - roleary, on 10/12/2007, -1/+12I agree with Brian. It's stupid because:
1) It's ridiculously long
2) I know it's an example, but this test is so simple I would never create a separate method for it ( if ( password != username ) ).
The idea that you can tie this to requirements doesn't hold much weight either. How do you verify customer requirements? By looking at all your method names? I sure hope not.
All programming languages include a method of documentation for a reason. Hopefully you have a standard for the format and content of your documentation. This should include things such as pre-conditions, post-conditions, method summary, and sometimes... if you're good... traceability back to requirements.
Embedding requirements traceability into your actual code by creating method names that have 14 words (71 characters) is NOT good software practice (in my opinion and experience). In fact, I notice the author likes to keep his software within 80 characters per line, kinda hard to do that when you need 74 character to call a method. - lord2800, on 10/12/2007, -1/+10I am currently employed as a software developer and I would say that of these 5 habits, most of them are either described in detail elsewhere in the realm of software design or just plain wrong. For example:
Habit 1 dictates in an almost nazi-ish fashion that constructors should do nothing more than load data into its' members. I disagree with this wholeheartedly, in the sense that a constructor's job is to initialize an object to some determinable state. If this means going into the backend and retrieving the account data tied to some account, then so be it. The initialization of an object /includes/ any logic to get other associated data, such as account status and information. The developer should neither know nor care how an object gets its' data, it should simply know that it is there. He should also not have to call any method to "initialize" data from a remote store -- it should be taken care of in the constructor, like a good object should do.
Habit 2 whines about naming conventions. Here's a helpful tip for any of you going into a real programming job: Naming conventions are whatever your manager dictates. You generally don't have a choice, nor should you care. If he dictates that objects are all to be named after marsupials and functions are to be named after their bodily functions, so be it(my advice to you in this situation would be to quit, but that's another story). longNamesThatTakeUpALotOfRoomForNoApparentReasonOtherThanToBeDescriptive() are annoying to type and even harder to keep straight. So what if it describes everything that the function/class does? That's the point of documentation, not code.
Habit 3 is slightly more reasonable, it only demands that objects provide a limited set of functionality. This is something that should be dead obvious to ANYONE who has taken any sort of object-oriented design class, because it's the key component behind object-oriented design.
Habit 4 is an extension of Habit 3, requiring you to design encapsulated methods that affect only the data that they are directly attached to. Again, see Habit 3 for an explination of why this doesn't even need to be mentioned.
Habit 5 is the most pointless of all -- dictating in a preposterous manner that Behavior Methods should be able to be called in any order. Again, this is the realm of object-oriented design, not design habits. Anyone with a grasp of basic analysis skills can tell you that it would be a mess to do it The Other(tm) way.
All in all, I expected more from a KRose post. Instead, I get an article that half rehashes things you should've learned in a C++ class thrown in with a few completely wrong things. - ahawks, on 10/12/2007, -0/+8Agreed:
TestPasswordEqualsUsername() would be just fine.
Then again, most of us have some form of autocomplete by now :) - brianegge, on 10/12/2007, -5/+13"Using the method name testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername() clearly conveys the intent of the test and, therefore, the requirement of the software."
This is the stupiest thing I've ever read. - omegadan, on 10/12/2007, -0/+7Agreed. However, the alternative is pretty bad to. We had a guy at my place who liked to remove all the vowels from this function/variable name, so he would write that funciton name like: "tstRqstdPwIsNtVldBCItMstBDfrntThnUsr"
I am not joking :) We have thousands of lines of illegable coe - superpatty, on 10/12/2007, -2/+8I finished a java class a few months ago and they didn't even mention four of those five habits which can be very useful and are very intelligent
think I'm going to email this to my teachers :) - missflibbles, on 10/12/2007, -4/+10no.
6. ???
7. profit! - puggy, on 10/12/2007, -1/+6Good practices, although not directly related to profitability.
- elnerdo, on 10/12/2007, -2/+7Because it takes thirty seconds to type?
- vandalet, on 10/12/2007, -3/+7Interesting read. good to know for the young programmers just getting into the business.
Front page in 4-3-2- - Eeqmcsq, on 10/12/2007, -1/+5"I want short simple method-names."
I agree with you. By the time I mentally read through the function name "testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername()", I might forget what the rest of the code was doing, especially if I'm already trying to hold several complicated pieces of code in my head. The simpler the name, the simpler it is to put it in your head along with everything else you're already trying to keep track of. - dustyshadow, on 10/12/2007, -1/+5I'm glad I didn't go to your school. I was just about to post that each of these things seem to be things that most developers do, not just profitable ones. The article just states the obvious IMO.
- v3xt0r, on 10/12/2007, -5/+9probably because method names should not exceed (approx) 20 chars.
If you can't write comment blocks that clearly convey the intent, then you shouldn't be programming. If you think that comment blocks are a bad thing, then you have your head up your ass. - morphie, on 10/12/2007, -0/+4"Has nothing to do with long method names, but with your programming behavior. It might very well be the case that your short and simple names are unreadable for other programmers."
That might certainly be the case, however I never heard any complains about it. For descriptions you must use comments or doxygen. And use a decent IDE which understands doxygen, so it gives you descriptions in the autocomplete-boxes. :)
I think 'UsernameEqualsPassword' would be a much better replacement for 'testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername'. You instantly see what it does and it does not take more than 20 chars. The fact that it has something to do with requirement i.e. 'REQ4528' is something you put in comments. That's the way. :) - transeunte, on 10/12/2007, -1/+5"Uhm, if you use a pre-1980 compiler maybe?"
No. Ever heard of common sense?
There are things you are allowed to do, but shouldn't. Naming a method with such name is one of those things. - JimNtexas, on 10/12/2007, -0/+4This was a really lame article. The stuff about ctors is just silly, as is the LongNamesAreGood nonsense.
- RailsAddict, on 10/12/2007, -0/+3Its a friggin test method, you type it once, and never again. Now, if that was a method names sticking off a model class or something:
user.tryToLoginUsingTheUserNameFromTheForm(name, password)
then it'd be something to complain about. Other than that though, this article didnt really hit the mark. The "habits" should be common sense to anyone developing software with modern OOP langauges. - abqjudy, on 10/12/2007, -0/+3Might be good to share this with team members who dont understand the needs for a program. If you can explain it in terms of flexibility, user ease of understanding, thus profitability, you might just be ahead of the game.
- folletto, on 10/12/2007, -0/+3Sure, but we have to note that a short name is more readable than a long name, so it's better to think if there's a name under a limit of chars that could convey the meaning as well as a longer name.
It's a matter of "code usability". Even if we don't have limit due to modern editors and compilers, we always have to think about readability. A shorter name is FOR SURE more usable tha a longer name.
So, the sentence: "probably because method names should not exceed (approx) 20 chars" even if it could be a limit too low (20 chars) I don't think it's wrong. It doesn't say "it MUST not exceed", it says "should".
For my own point of view that means: "think if you could be clear AND concise, if you can't, just type more".
I think this is a critical point, and that should enough. I could also add that a too descriptive text limits the method functionality in a future iteration, so it might broke the interface of that class just because we wanted to describe the entire functionality in its name. Even if one shouldn't think too far in the software iterations (as XP states, if you agree with it) being too descriptive isn't so good. If you want to describe, use the documentation. That's why it's there. ;)
However this last point weights 1% in the answer. The part above is the 99% of the "why it should be done". :) - Haplo, on 10/12/2007, -1/+3"Every time I saw long method names or database-table names, the software wasn't readable and therefor bad maintenance was the consequence. :)"
Has nothing to do with long method names, but with your programming behavior. It might very well be the case that your short and simple names are unreadable for other programmers. - nonsequitor, on 10/12/2007, -0/+2I buried it too. Pretentious Tripe. I'm a highly profitable Software Engineer, but I work in embedded RTOS's, guess that means I'm an anomaly.
I hope my boss doesn't read that, he'll think I'm worthless, all that assembly, not a single constructor. - gd007, on 10/12/2007, -0/+2that is too short for me.
- Haplo, on 10/12/2007, -0/+2"in the sense that a constructor's job is to initialize an object to some determinable state. If this means going into the backend and retrieving the account data tied to some account, then so be it."
Best to move such a complicated task to a separate (or several) methods, because then one can test each method stand alone. Also note that a good programmer is able to know when a rule (keep constructors as "small" as possible) should be followed, and when not, without delivering bad code ;-)
"Naming conventions are whatever your manager dictates."
I do recommend to follow the style guide of a programming team, not of a clueless manager though.
"So what if it describes everything that the function/class does? That's the point of documentation, not code."
Your mistaken: picking a good self describing function name is better compared to some documentation. If done good, the name is much easier to remember, and can be considered self documenting. It also might stop some "programmers" from stuffing everything in a method. The author of the article recommends small building blocks, because those can be tested easily. And of course, the long name in the example is a rare one, if it ever occurs. If you're a good programmer you have understood the message, instead of nit picking about the number of characters ;-)
"This is something that should be dead obvious"
Yes, well, maybe do some pear reviews of code generated by self proclaimed skilled OO programmers :-)
"I get an article that half rehashes things you should've learned in a C++ class"
Yes should. I have seen often so many bad coding that people should have learned how to avoid, that there is clearly a need for such an article.
"thrown in with a few completely wrong things."
Somehow you forgot to give good arguments for what's wrong though. - lord2800, on 10/12/2007, -0/+2"Best to move such a complicated task to a separate (or several) methods, because then one can test each method stand alone. Also note that a good programmer is able to know when a rule (keep constructors as "small" as possible) should be followed, and when not, without delivering bad code ;-)"
Of course complicated and/or reused functionality should be abstracted away. I'm not advocating the complete removal of functions, I'm denying the ridiculous claim that a constructor should do nothing more than set up its' data members to some static state(unless said static state is what's actually desired...). The point was that the constructor should take care of /all/ functionality relating to the initialization for that piece of data. A developer should not have to do something to the equivalent of:
Object o = new Object("stuff here"); o.initialize();
because that logic should've been taken care of in the constructor in the first place.
"I do recommend to follow the style guide of a programming team, not of a clueless manager though."
I meant that in an almost sarcastic manner. However, I have had jobs where even the coding style was dictated in the spec. It was an interesting lesson in how much I rely on my own personal style to give me hints about the code.
"Your mistaken: picking a good self describing function name is better compared to some documentation. If done good, the name is much easier to remember, and can be considered self documenting. It also might stop some "programmers" from stuffing everything in a method. The author of the article recommends small building blocks, because those can be tested easily. And of course, the long name in the example is a rare one, if it ever occurs. If you're a good programmer you have understood the message, instead of nit picking about the number of characters ;-)"
I'm not nitpicking the number of characters, I'm nitpicking the need to even think about describing every bit of logic in the function as part of the function name. If you want to know how a function works, you should refer to the documentation, not the naming convention. A good name for the example(instead of the gaudy monstrosity used) would've been "validateUserName". Clear and to the point, without overcomplicating things. You could even section that out into two function calls: "validateNameLength" and "validateNameContent" that "validateUserName" calls, should you have a need to call them
"Yes, well, maybe do some pear reviews of code generated by self proclaimed skilled OO programmers :-)"
You mean peer? And for the record, I haven't seen a single real-world program that follows good object-oriented practices.
"Yes should. I have seen often so many bad coding that people should have learned how to avoid, that there is clearly a need for such an article."
Which is why those developers should never have been hired in the first place. I blame the schools for allowing shoddy learning practices, the job employers for using HR people to hire programmers without a second screening against a real programmer, and the people themselves for not properly learning and comprehending the material. Programming should not be something you do because of the money, just like you shouldn't be an Actuary for the money(which, by the way, they make REALLY good money -- if you like doing math all day).
"Somehow you forgot to give good arguments for what's wrong though."
Meh, I wrote the ending before I finished the post and forgot to review. Sue me. - Haplo, on 10/12/2007, -0/+2And Perl :-)
Yet people stick to "new" most of the time, especially no to confuse others. I have written "connect" and other constructor methods though, but they are rare.
But the constructor, like it's name implies should *construct* the object, and nothing more. I know people who even prefer to initialize the object in a separate method, which is not called from the constructor, and I think they have a point. - folletto, on 10/12/2007, -0/+1Hehehe. That's just what I've commented to the author: into the constructor call other descriptive functions if you want to do complex things, because sometimes a constructor MUST do complex things.
- theevilmonkey, on 10/12/2007, -0/+1I tend to agree with roleary, in that this is kind of basic/common sense stuff. Without having a decent understanding of common mistakes belaying software development, we'll never make the kind of progress the hardware engineers have :)
- transeunte, on 10/12/2007, -1/+2I don't remember saying that 20 characters was the limit. Maybe it's because I did not.
- nonsequitor, on 10/12/2007, -1/+2Meta-Data Tags in the function headers make requirements tracability simple. It also helps if you have intermediate docs between Customer Requirements, System Requirements, High level design, and Low Level design, with tracability from that into your code to your tests. Top to bottom and bottom to top.
- binarybyron, on 10/12/2007, -0/+1hehe, you think that's bad. I've seen a method with 13 parameters in production code.
- Whifflepuff, on 10/12/2007, -0/+1Good article, I agree with almost everything ...
testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername
That is just plain silly. - NinjAlt, on 10/12/2007, -0/+1Ugh. You people are sheep. You eat up everything kevin posts or say. He hasnt had one article that hasnt made the front page. More proof that the digg system is broken.
- supervapio, on 10/12/2007, -0/+1Really good. I've never paid so much attention to this before.
- Dotnetsky, on 10/12/2007, -0/+1Another "holier than thou" "I'm the expert" article that simply restates the obvious. For real information about readable code, explicit code, and good software patterns, try Martin Fowler. And, the language is unimportant.
- thund3rstruck, on 10/12/2007, -0/+1On another note, it's amazing at how similar Java syntax looks like C# (or actually C# looks like Java).
I may have to take another look at Java.... - nonsequitor, on 10/12/2007, -1/+2This article is very limited in scope. Your teachers have a responsibility to teach you the underlying theory behind software development. This article focuses on a few "best practices" for a very specific type of developer, web service development. Your teachers are preparing you to enter any number of specialties, whether it be embedded systems, web service development, databases, application development, operating systems, compilers, etc...
These skills are very specialized to web services and object oriented programming, basically it underlines the importance of high cohesion and low coupling, a phrase you should be familiar with after an object oriented design class.
A glaring hole in that article is the lack of mention of design patterns. I've found working on large teams in an enterprise development a working knowledge of all the common design patterns is invaluable. Its a very effective way of communicating to your teammates how you plan on solving a certain problem since those patterns carry a lot of meaning. We'll use some decorators to do that, or I'll make a delegate class, etc convey very complex meaning in an economy of words. - sandrat44, on 10/12/2007, -0/+1I posted an alternative explanation - I always found real world examples helped me understand these better. But, yeah - overall, good points with some uh, iffy points.
http://gertica.typepad.com/cfgertica/2006/08/5_habits_of_suc.html - pankaj23183, on 02/06/2009, -0/+0i am new to JAVA and my instructor didn't teach this....very useful article
http://www.futurismtechnologies.com/ - vonskippy, on 10/12/2007, -5/+5#6 - Make Money.
- BenWilson, on 10/12/2007, -0/+0Profitability is relative, I suppose. I would conclude from the article that those who follow these practices are able to write code that forces others to spend less time trying to figure out what they are doing---including themselves six months later. So, it's saving time in that regard which is the greater profit in a schedule-intensive environment.
- russryba, on 10/12/2007, -0/+0I would say that both the example given and the shorted TestPasswordEqualsUsername() above are both wrong at the core. Consider your security requirements will change next week and you'll end up with the following functions...
testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername()
testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsernameReversed()
testRequestedPasswordIsNotValidBecauseItCantBeACommonName()
testRequestedPasswordIsNotValidBecauseItIsTooShort()
testRequestedPasswordIsNotValidBecauseItIsANaughtyWord()
The *TEST* is "CustomerAccount.IsPasswordValid()"
The *RESULT* would be...
enum {
VALID_PASSWORD, // Valid passwords return 0
INVALID_PASSWORD_SAME_AS_USERNAME,
INVALID_PASSWORD_TOO_SHORT,
INVALID_PASSWORD_DICTIONARY_WORD,
INVALID_PASSWORD_USERNAME_REVERSED,
INVALID_PASSWORD_DATE_OF_BIRTH,
INVALID_PASSWORD_PREVIOUSLY_USED_PASSWORD,
etc, etc, etc
}
You can quickly check if the password is valid or not if it returns zero, or check the return code for more information.
Now I know there is a fair share of programmers here, but ignore the syntax. The core concept to remember here is don't create separate functions for every possible test case. If your putting the word BECAUSE into a function name then you're most likely making a mistake.
I've been doing this for 15 years now and no simple list or magic bullet will work. The best thing most programmers I've met could do to improve is spend LESS time at the keyboard and more time THINKING about what they are going to do when they get there.
This is why pair programming works so well. You've got one guy typing while the other thinks. Thinking correctly is the real habit of highly profitable programmers. Maybe that's different for developers. ;o) - topicnation, on 10/12/2007, -0/+0Wonderful. I don't like such articles.
- ducttapekz, on 10/12/2007, -0/+0@bheilig
So the solution is to switch to a programming language that no one uses and resources cannot be found? Then you could make a good constructor name and it would be easy to support. . . - ducttapekz, on 10/12/2007, -0/+0Decent article, horrible title.
-
Show 51 - 63 of 63 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is