You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2024. It is now read-only.
As we discussed in RMG meeting, it would be a good time to format the code once we come to the release stage.
Eclipse has a built-in formatter style named Java Conventions and if you don't have any objections, I plan to use it with modifications based on your suggestions. It has a mixed (both tabs and spaces) indentation, attached braces and 80 character line limit for code and comments. Let me know any of your preferences, if they differ from the default settings.
Currently, I plan to modify the default style by enabling:
Header comment formatting,
Never indent line comments,
Never indent block comments,
Off/On tags.
If you want to keep the original formatting for certain files, you can add //@Formatter:off line to the beginning of the code.
Establishing a coding convention is a good idea. I think the Eclipse defaults are generally fine. Some additional thoughts:
Hard vs. soft tabs. Over the years people have used both (with different numbers of spaces per tab), and the result is that many of the files are really difficult to read, no matter what your editor is set to. An informal poll of the people sitting around me and recent programming language style manuals suggests soft tabs (4 spaces per tab) is the way to go. This is also nice for the Fortran code, for which tab characters are not technically allowed.
File encoding. I suggest UTF-8 for everything, since most things are just plain text. This hasn't been as much of an issue, but still worth enumerating.
Function and variable naming style. I think everyone uses camelCase (as taught in most Java textbooks I've seen).
Comment style. Javadoc format seems like a good choice here.
If we were sticking with Java, I'd also want everyone to learn how to use JUnit to write unit tests, but since we're probably switching to Py I'd say learn it in Python instead.
Also, we should update the headers at the top of the source files when we clean up the formatting, e.g. to update the copyright date.
As we discussed in RMG meeting, it would be a good time to format the code once we come to the release stage.
Eclipse has a built-in formatter style named Java Conventions and if you don't have any objections, I plan to use it with modifications based on your suggestions. It has a mixed (both tabs and spaces) indentation, attached braces and 80 character line limit for code and comments. Let me know any of your preferences, if they differ from the default settings.
Currently, I plan to modify the default style by enabling:
Header comment formatting,
Never indent line comments,
Never indent block comments,
Off/On tags.
If you want to keep the original formatting for certain files, you can add //@Formatter:off line to the beginning of the code.
There is also a nice documentation on suggested Java conventions on Oracle web site for future reference. (http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html)
The text was updated successfully, but these errors were encountered: