You are right. My answer was not clear and is wrong when reading as it is written.
When i say "We are compliant with PSR-2 and check is 100% ok", you must read "We already have rule to define which coding rule to follow (my mail was to answer to Florian asking rules) and this rule we acted are PSR-2 compliant, except 2 points." and "We are also currently compliant we all rules whose test was automatically implemented into our coding rule checkstyle sheet dolibarr.xml" So you are right on 2 points: -exception is, in fact, larger that 2 points: there is also * PHP closing tag is never omitted and * using var instead of public properties that is used currently for new code so new code is not PSR2 - 2 rules but PSR2 - 4. I will add this 2 points into wiki too soon as they were forgotten (And when we forgot it wiki, we forgot it everywhere like it did myself). -very old code is far away from our rules. this is true. This just means we must switch slowly to match dolibarr rules. I say "slowly" because i know automatic tools are creating a lot of regression so we must be prudent on this, but work is opened. For choice of PSR, i don't think we must spend too much time/troll on this, PSR is as bad as good as useless. Following our rules, even if it's not 100 PSR-2 is already a high constraint. 2014-02-24 16:45 GMT+01:00 Doursenaud, Raphaël <rdoursen...@gpcsolutions.fr> : > FWIW PSR-2 also includes PSR-1 and PSR-0. > Well, Dolibarr is very far from being PSR compliant, even with the > indentation (tabs instead of 4 spaces) and line length (unlimited vs, mmm > well, unlimited with a recommendation to keep them under control, > preferably under 120 chars, 80 chars being optimum) discrepancies. > > A few examples: > Some Dolibarr files declare symbols and cause side effects > Most Dolibarr classes are not named in StudlyCaps. > Most Dolibarr methods are not named in CamelCase() > PHP closing tag is never omitted. > Use of var instead of visibility in most, if not all, class properties > Visibility is not set on most methods. > Opening braces, control structures and spaces don't meet PSR-2 > requirements. > > Now, what should we do? > Keep using the legacy style or make the code PSR-2 compliant ASAP? > > You know I vote for the later. > > What about PSR-3 and PSR-4 ? > I think we should adopt the whole PSR package or use any other > well-defined coding style available (PEAR, Drupal, Wordpress...) rather than > rolling our own. > > Also, other developers, you have an opinion, please chime in and speak now > or forever hold your peace ;) > Shall we/you/I start a poll ? > > Cheers, > > > 2014-02-24 11:16 GMT+01:00 Destailleur Laurent <e...@destailleur.fr>: > > We discussed on that few month ago but i forgot to save conclusion onto >> developer wiki documentation. I added them onto page: >> >> >> http://wiki.dolibarr.org/index.php/Language_and_development_rules#PHP_Norms >> >> Conclusion is that we use PSR2 with 2 exceptions (see wiki updated page). >> And there is a checkstyle page to check we follow this. >> >> I work with eclipse 3.7 and if you set up correctly (see page >> http://wiki.dolibarr.org/index.php/Environment_and_development_tools and >> http://wiki.dolibarr.org/index.php/Environment_and_development_tools_-_Optionnal_components), >> everything looks fine for me. >> >> >> 2014-02-23 21:58 GMT+01:00 Florian Henry <florian.he...@open-concept.pro> >> : >> >>> Hi, >>> >>> I was working on stuff in dev branch, and it was long time I didn't >>> get to commit. I copy-paste some code lines from other branch or module (to >>> integrate them into the core) and I've seen a lot of the travis "style" >>> syntax check come into pull request. >>> >>> I use Eclipse Kepler (4.3) + PDT as IDE. What is yours ? >>> - Notepad++ >>> - PHP Storm >>> - Eclipse Indigo (3.7) + PDT >>> - Eclipse Helios (3.6) + PDT >>> - Vim >>> - others >>> >>> This question is to know, if it's hard for you to do "auto format" >>> code ? >>> >>> After lot's of try and adjustement, I think I found a PHP->Code >>> Style->Formatter Dolibarr syntax that is complaint with the >>> dev/codesniffer/ruleset.xml. >>> I put it in attachement. Mostly base one PSR-0 (the default into >>> Eclipse Kepler 4.3) >>> I think that the current code style format is the one use by >>> default by Eclipse Indigo (3.7) or Eclipse Helios (3.6), a code style that >>> I didn't found by defaut into Eclipse Kepler and seems not to be a PSR-0 or >>> other standard code style PHP format. >>> >>> Well, I think it would be nice to use a normalize code style format >>> like PSR or other one. I think the devcamp will be a good time to do it. >>> What do you think about it ? >>> >>> I know I will hate myself, because when I will want to integrate >>> some code lines from others branches I've done for some projets, a >>> compare/diff between old and new files will thanks to me for this brilliant >>> idea. Ok, so lets go to auto format the all code previous branch and it >>> will do the tricks. andafter that no more problem with formating check >>> style. >>> >>> I also know that, for Dolibarr, code style PHP format is not a >>> important matter. But if it can be done with the agreement of lot's of >>> person it will be nice. >>> >>> Regards. >>> >>> -- >>> Florian HENRY >>> florian.he...@open-concept.pro >>> +33 6 03 76 48 07 >>> http://www.open-concept.pro >>> Twitter : @_Open_Concept_ >>> >>> >>> >>> _______________________________________________ >>> Dolibarr-dev mailing list >>> Dolibarr-dev@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >>> >> >> >> -- >> Laurent Destailleur (alias Eldy) >> >> ------------------------------------------------------------------------------------ >> Social networks of my OpenSource projects: >> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >> Dolibarr Facebook: https://www.facebook.com/dolibarr >> Dolibarr Twitter: http://www.twitter.com/dolibarr >> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >> AWStats Facebook: https://www.facebook.com/awstats.org >> AWStats Twitter: http://www.twitter.com/astats_project >> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> Dolibarr-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > > > -- > *Raphaël Doursenaud* > Directeur technique (CTO) > Expert certifié en déploiement Google > Apps<https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> > +33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10 > > <http://gpcsolutions.fr> > http://gpcsolutions.fr > Technopole Hélioparc > 2 avenue du Président Pierre Angot > 64053 PAU CEDEX 9 > SARL GPC.solutions au capital de 7 500 EURO - R.C.S. PAU 528 995 921 > <https://www.google.com/a/partnersearch/#partner?partner_id=46687933_a0n60000000sqpWAAQ><http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions> > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- Laurent Destailleur (alias Eldy) ------------------------------------------------------------------------------------ Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/astats_project
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
