today.java.net — "Software developers who have the ability to create and maintain quality software in a team environment are in high demand in today's technology-driven economy. The number one challenge facing developers working in a team environment is reading and understanding software written by another developer. "
Aug 24, 2006 View in Crawl 4
locnguyenAug 24, 2006
Once you graduate and get a job in the real world, you'll find your "education" was a bit of a rip off.
binarybyronAug 25, 2006
hehe, you think that's bad. I've seen a method with 13 parameters in production code.
jimntexasAug 25, 2006
This was a really lame article. The stuff about ctors is just silly, as is the LongNamesAreGood nonsense.
gd007Aug 25, 2006
that is too short for me.
bitserfAug 25, 2006
Ok, so to be highly profitable, I need to get into those five habits? Got it. Thanks.Heh. (-1 Irrelevant Title To Garner Page Hits)EDIT: Oh I see, he's an "agile" developer. Now it all makes sense :)
railsaddictAug 25, 2006
Its 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.
morphieAug 25, 2006
"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. :)
benwilsonAug 25, 2006
Profitability 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.
russrybaOct 25, 2006
I 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)
supervapioApr 22, 2007
Really good. I've never paid so much attention to this before.
topicnationMay 1, 2007
Wonderful. I don't like such articles.
pankaj23183Feb 6, 2009
i am new to JAVA and my instructor didn't teach this....very useful article<a class="user" href="http://www.futurismtechnologies.com/">http://www.futurismtechnologies.com/</a>