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 Celine: this rule as been done because when you create a boolean attribute (available) and ask to automatically generate getter and setter, then a method isAvailable is automatically created. If you create an attribute isAvailable, then a method called isIsAvailable would be created.

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 ) Celine: the purpouse of those rules is to make the code homogeneous, and if someone reads a class it will be clearer if all classes are organized the same way. By the way, the order listed here are mostly followed already.

• PRES-10

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

• PRES-16

Patrick: as Cedric I prefer in the same line Celine: both approaches have pros and cons, as I worked with both standards, I found clearer when the extends, implements and throws are on a new line (but this is only my opinion ;) )

• 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. Celine: Rules may not be applicable for generated codes. But they're specially done for developpers.I think it is possible to unplug the checks on the generated files.

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

• COMM-07:

Here you write the contract, in math you have to write if the parameter can be null if it is possible inform about the complexity of the algorithm n2 n3 logn

• COMM-12

Patrick : no! conter example if you apply a sort on a structure, you can explain in 3 lines you your contract and then you explain which algo you implments or resue

• ARCH-08

Patrick: where I put my developper doc (my model etc..). This is developper doc so I must be in the plugin not in the separate plugin to avoid that develooper forgot to modify it. When he sees the model in the plugin they cannot foget it.

• 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