> Miguel, > > Don't worry. You can have it exactly that way. Tell me if there is > anything WHATSOEVER in Viewer.java, Draw.java, or DrawRenderer.java > that you don't like. I just committed automatically formatted versions > of the latter two.
OK. Don't feel bad. > Miguel wrote: >> >> I *must* have the following: >> - 80 character lines > > yup, that's there - no problem. Understand, I just REALIZED it was > there. I know I've been ignoring this; I'm a changed person today. > >> - newline at the end of the file > > that I can do by hand. You mean one final blank line after the last > bracket close, right? I will check to see if Eclipse does that....No, > it doesn't. No. I do not mean a blank line.. However, one of your files ended with a } on a line by itself. That is, there was no newline terminating the last line of the file. (Many compilers used to have problems with this ... and countless hours have been lost because the file did not end in a newline. emacs complains and asks for confimation before letting you save a source code file that does not end in a newline.) >> - 2 space indentation > > not a problem. Totally automated > >> - no tabs > > none ever. I don't think I can even introduce them in Eclipse. > >> - no blank space line at the top of the file > > not a problem. I have seen several files with this. >> - no comments that start with /** unless they are javadoc > > ah, this I'm glad to have explained. > >> >> If I see files that do not conform to this then I will reformat them >> every >> time. > > Well, then, you're in luck! There should be no need of that. > >> >> If you feel that we should change these rules then we can talk about >> that. >> > > I think these rules are great. I suggest adding: > > --No blanks at the end of lines. Agreed > --Double (4-space) indent for continuing lines due to concatenation or > logic. Here is an area where we differ. When parameters to functions get broken to the next line then they should line up vertically with the other parameters. > I'm sorry if you spent a lot of time doing this by hand, I don't do it by hand. emacs does it. > and I just > messed it up with the press of a button. I have Eclipse now set up for > > void method(xxxxx xxxx, xxxx, xxx xxxx, > xxx xxx) Correct. > as Nico instructed. I think that looks very nice. In addition, Eclipse > makes a double indent for concatenation and logic breaks always with > the operator at the beginning of the next line. I'm pretty sure that's > what you said you liked. I prefer operators at the end of the line, but I won't complain if Eclipse puts them at the beginning of the line and you can't control that. > Then, I saw a variety of blank-line white-space conventions. This is a > whole slew of Eclipse conventions. For example, when you saw all those > > TransformManager transformManager; > > PropertyManager propertyManager; > > etc. all with blank lines, you removed the blank lines. Well, they > were just there when Nico, I think, ran the formatter in Viewer.java. > I set the 0-line parameter for that, and they are gone. Forever. In general, I do not like extra vertical white space. > Eclipse is VERY STRICT about these and will set them up exactly as we > want, whatever that means. > > I guess my bottom line is this: > > I agree 100% with everything you say, and now that I know it can be > done automatically, I suggest that it SHOULD be done automatically. > None of us need to waste time on this. Probably one of us, not all, > should be doing it. Or, if we all do it, then we need to do it at a > time when we all are taking a break from programming. Luckily I had > only changed a couple of things in Viewer, or I'd still be sitting > here clicking through all the blank line changes. > > I'd really like us to agree on an Eclipse-friendly format. Even if you > don't like every single thing it does (although I can't imagine why), > it will be a great benefit to have this done automatically. I agree. emacs has been doing this for decades. I am sure that Eclipse can mimic the emacs indentation style + more stuff. FYI ... many professional projects will not allow one to check in code unless it conforms to indentation/style rules. Miguel ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
