Talk:Papyrus/Neon Work Description/Discussions/Development rules

Development Rules (Talk)

• NAME-06

Patrick: according to me, the name must be understable. I dislike acronyms concatenations and abbreviations. An exception has been done for gmfdiag

• NAME-22

Patrick: I have the same point of view as Cedric, for boolean variable I prefer a prefix with is

globally for all presentation rules, i think that is to strict.

• PRES-01

Patrick: I prefer not to be so strict in the structuration of the code. In IDE, now you can order properties, operations as you want (alphabetic...) Nevertheless: On remarks about inner class. I do like it. I someone add a ne inner class, it has to write a solid argumentation (if no a lot od developper will write the code in one files ;D )

• PRES-18

Patrick: Interesting, but I do know if it can be applicable to papyrus: the code that has been generated is greater than 2000 lines of code per files in some classes.

• PRES-10

Patrick: 250 characters is better, screens are greaters than in the past.

• PRES-16

Patrick: as Cedric I prefer in the same line

• TIPS-13

Patrick: Why?

I use an Interface of define constants of stereotype names.

• TIPS-17:

Patrick: I thanks that is more important is to make a good java doc. explains that a parameter and the returns can be null Explains that the level of complexity n2 n3 or log n. if if is n3 or n4, we know the prerimeter to improve the performance. We have not to forget first we need fucntionality and then we can improve. It s better when the algo is efficient, but it is important to be not so strict to make review from all contributors.

• TIPs-24-29

PatrickI think it is to restrictive

• TIPs-30

Patrick the super class in the method must verify when it is possible. How to test it? the problem is imlicit contract, it must be written in java doc.

• TIPS-33

Patrick I do not like, when i write the code, I use a contract approach, I return by taking account contract and then I write my algorithm, In this manner the code is readible and I avoid a lot of indentation.

• TIP-35:

Patrick I do not like it, I find it no readable.

• TIP-68:

Patrick the use of static has implication. So static use must be motivated and not use it when is possible

• TIP-73:

Recursive algorithm can be powerfull. I depends the code is made.

• COMM-06

Patrick the contributor is already written in the header, so it is not usefull to add it in the javadoc of the file. tI thinks that the version is not usefull, the version is managed by a git.

• ARCH-12

The string externalisation is already in place, but most of the string are not placed into a specific file: messages.properties.

I don't know if this could be done in Papyrus for the warnings, labels or other text messages.--Céline Janssens [ALL4TEC] (talk) 09:29, 9 July 2015 (EDT)

• SONAR

Why not activate the sonar instance for our project?: https://wiki.eclipse.org/Sonar