Hi All,
The Checkstyle rules have been discussed along with Rémi as a
basis. In order to have all the same way to code, and to have an
homogeneous code.
Several rules can be different from some habits, but the problem
with the habits is that they are all differents ;)
The formatter should give you the standard to be used.
None of the rules is blocking ! So if you have a really good reason
to not follow checkstyle indication, please document your
decision.
Nevertherless, if there are inconsistancies between the Formatter
and the Checkstyle, then we should obviously make it sync.
About the multi return...
This point has been deeply discussed before to decide to prefer a
single return statement.
In a maintainability point of view and in terms of debugging,
the single return statement is preferable.
I know that a lot of existing sources already use multiple return
statements. That is why we keep this rule as a warning and not as
an error.
The purpose is to improve the code formatting as soon as a source
is modified.
For long term, that should make the code stronger, homogeneous, and
maintainable.
Best regards
Céline
Le 21/06/2016 à 18:45, Christian Damus
a écrit :
Hi, Ernesto,
If we change the formatter profile, that should be done in
the org.eclipse.papyrusrt.umlrt.core bundle, which the Oomph
master for all of the project settings. From there, the Oomph
project configuration tooling will push the change to all of the
other projects. So, you don’t have to worry about changing
all of the settings files (Oomph does).
I would like to see a lot of changes in the Checkstyle rules,
too. I haven’t got time to make a list now, but we should
discuss it as a team (maybe in a Google sheet). There are so
many warnings in clean code that the current checkstyle profile is
basically useless.
Christian
On 21 June, 2016 at 11:14:32, Ernesto Posse
(eposse@xxxxxxxxxxxxx) wrote:
I'm reformatting the code generator to conform to the
checkstyle rules introduces, but I have found a few problems. In
particular, it looks like there are some inconsistencies between
what the formatting does and what checkstyle approves. For example,
I have an enum with several entries which is formatted in two
lines, but checkstyle complains that the first line is too
long.
There are other problems as well. I consistently run
into a warning saying that only one return statement is allowed per
method. This feels quite stringent.
Or the requirement that every attribute has a
javadoc.
I was wondering if we could relax some of these
rules.
I see that the the checkstyle rules are in releng/oeprt.oomph/checkstyle. But what if we
wanted to change some of the formatting rules? Would we have to
change every single .settings/org.eclipse.jdt.core.prefs
file?
(I'd like to be able to write each enum entry in a
separate line without checkstyle complaining and without the
autoformat putting them in one line.)
--
Ernesto Posse
Zeligsoft
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
|
Céline JANSSENS
Software Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net |
|
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev