Excellent points - though to be fair to the vi/emacs crowd, at least some of that is because this "hardcore" guy is not that good. Rendering identifiers differently depending on what kind they are is very useful and AFAIK not something vi/emacs can do.
NB: Don't hand-write your equals and hashCode, don't let your IDEs generate it either, use Project Lombok :) http://projectlombok.org/ On Nov 24, 8:34 pm, Andreas Petersson <[email protected]> wrote: > Interesting discussion so far about vi/emacs vs IJ/Ecl/NB. There were > lots of arguments concerning the PERSONAL productivity of a single > programmer. > For my part, i personally stick to IJ, i used that since 2001 (with a > 1-year intermezzo in Eclipse) and has since not disappointed me. > Previously i did not object if someone else used notepad/vi/emacs until > I experienced working with them in a team: > > The problem i see is you have to look at the productivity not only of a > single programmer but rather the combined productivity of a whole team. > > Some anecdotes supporting this: > In one of my teams we had a single programmer insisting on using vi > only. He was coding javascript with proclaimed 3 years of experience. > After his checkins I opened IJ and saw 2 yellow and 3 red markings. > Without knowing javascript i knew this was wrong and ideed those were > errors, popping up in some corner-cases. Also some html tags were broken > (like <div><span></div></span>) which would be trivial to detect and fix > with a decent editor. > > In other situations a 10-person team coding Java everyone wrote > auto-generated hashCode/equals methods, everyone was used to it. Except > the "hardcore" guy wrote them by himself leading to bugs and furthermore > he was dragging everyone down, because everyone had to re-check his > manually written methods for errors, while they could rely on most > auto-generated ones being correct. > > Also the practical method of keeping final immutable fields public > rather than private with a getter becomes unhandy if you cannot rely on > the fact that everyone in the team can trivially apply "encapsulate > fields" as a refactoring. > Convulated Naming conventions become obsolete if the IDE renders > different types in different colors. (members, local variables, > interface impl etc..). > The same holds true for many other "modern" coding techniques which rely > on good IDE support. > > my conclusion: In a team a single person not using top-notch tools can > potentially harm the productivity of everyone. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
