FWIW, and without wanting to get into a philosophical flame war - SS, the coding principles that you've listed are pretty right in line with the way I code as well.
The good news is that with Java and modern IDE's, code understandability is much less dependent on these details than it was in the "bad old days" (which, sigh, I am old enough to remember. Raise your hand anyone who has used punch cards!) Sunburned Surveyor wrote: > Larry, > > Maybe I am totally missing something with my programming style. I will > try to explain my reasoning for wanting this in a separate method, and > then you can correct whatever bad programming habits that appear. :] > > First of all, I really try to avoid chaining method calls like you > have done in your suggestion, especially in the argument list for a > method. (I know experienced programmers are likely screaming at my > stupidity at this point.) I do this because I believe it makes the > code much more difficult to understand. I know it is more concise, and > it may even be more efficient at run time, but these are not my first > goals when I write source code for a program like OpenJUMP. (These > chained method calls, which Jon loves, were one of my main obstacles > to understanding JUMP's source code.) > > I really beleive the key to OpenJUMP's survival is not speed, > efficiency, or even concise code. I beleive the key to OpenJUMP's > survival is the ease with which OpenJUMP users and non-programmers can > learn what is going on in the source code. We need to convert these > users to programmers if we want to maintain a strong developer > community. > > This effort to produce "understandable code" means that I try to use > lots of source code comments, and I try to never chain method calls. > > As an example, what you wrote as: > > argList.setListData(argManager.getLayers().toArray()); > > I would write as: > > Collection layers = argManager.getLayers(); > Object[] layersAsArray = layers.toArray(); > argList.setListData(layersAsArray); > > Now, one reason I always look for room to create "utility methods" is > so I can have concise code without the confusing side effects. So my > three statements become: > > DialogUtil.setLayerNamesAsListData(); > > This allows me to be concise and the programmer reading my code can > look at the setLayerNamesAsListData() method to understand my logic if > he still needs to. It also allows me to add Javadoc comments to the > method, which I wouldn't have been able to do if the logic was > embedded in the class file. > > Here is another reason why I prefer a utility method for this scenario: > > What happens when we decide to modify the behavior of the getLayers() > method? (Maybe we modify it to return an Iterator instance, or maybe > we have it return an array directly.) I don't want to track down all > of the instances of > "argList.setListData(argManager.getLayers().toArray());" in all of my > source code. With my technique I can just modify the > DialogUtil.setLayerNamesAsListData(); method. > > I know this type of change isn't likely in OpenJUMP's source code, but > I never know what changes future requirements or improvements might > bring. Utility methods insulate my code from these types of changes by > isolating the number of times I have to deal with them. > > It is important to remember that my point of view is somewhat skewed. > I am not a professional programmer. I hadn't written one line of > source code until I started using JUMP, and it is the only reason I > learned Java. Even though I program for other reasons now, I always > try to write my source code to be read and understood by someone just > beginning to look "inside the box". > > The Sunburned Surveyor > > > On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: > >> Why don't you just do: >> >> argList.setListData(argManager.getLayers().toArray()); >> >> and skip the whole method. >> >> Larry >> >> On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: >> >>> I have attached my implementation of the setLayerNamesAsListData >>> method. I was thinking about placing this method in Sigle's DialogUtil >>> class. >>> >>> Someone asked to see my implementation, and I didn't want to cloud up >>> the other thread, which has moved onto other topics. >>> >>> The Sunburned Surveyor >>> >>> P.S. - Did we decide if the DialogUtil class is the appropriate place, >>> or should I put it into a separate JAR? >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >> -- >> http://amusingprogrammer.blogspot.com/ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
