|
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
|
|
|
