PR #5 was submitted earlier: https://github.com/roundcube/roundcubemail/pull/114
Working on managesieve right now and just wanted to quickly share my find of an 10 level indent: https://github.com/roundcube/roundcubemail/blob/master/plugins/managesieve/lib/Roundcube/rcube_sieve_engine.php#L758 This is the first time that I'm considering breaking something up into separate methods. There's a 600 line if/elseif construct in there. I mean come /on/. -David On Fri, Aug 30, 2013 at 7:14 PM, David Deutsch <[email protected]> wrote: > PR #4 is in: https://github.com/roundcube/roundcubemail/pull/113 > > Also note that I'm keeping the gist updated: > https://gist.github.com/daviddeutsch/6376013 > > ...with PR links and information that was discussed. Might be useful if > somebody wants to write an updated Code Guideline later on. > > > On Fri, Aug 30, 2013 at 3:02 PM, David Deutsch <[email protected]>wrote: > >> Good question! (Also: shame on me for not finding those guidelines ealier >> O_o .../awkward/) >> >> I think the basic recommendation that PSR-1 makes on this are pretty >> sound: Make a choice and stick with it. As a personal preference, I use >> StudlyCaps for classes (this is a 'must' in PSR-1), camelCase for methods >> and under_scores for variables. I find that that helps separate the three >> concepts, even though it might seem like "hey, why do you use three ways of >> doing something". Because it's three separate concepts! >> >> From what I've seen in the plugins so far, it seems like RCM pretty >> consistently uses lowercase_underscored for all three. >> >> Sidenote: My IDE actually gives me a lot of funny warnings about the >> class names in RCM - something along the lines of "there is probably a >> conceptual error here, somewhere" I always imagine it standing before me >> with eyes twitching "dude, this aint right!" ;-) >> >> Sidenote 2: The Guidelines references PEAR standards. I used to really >> dislike those, particularly for the ~80 character line limit, which seemed >> silly ("Oooh, your b/w terminal can only do 80 characters per line!?"). >> Fast forward a couple of years and I absolutely love an 80 char line limit. >> It's like an addiction to shortness.* There are a couple of outdated things >> in there and I might forever think that 4 spaces is silly, but yeah, not as >> bad today ;-) >> >> *Sidenote 3: This also helped me come around on Namespaces, really. >> "use... as" REALLY helps keep lines short when using classes and >> particularly when calling static methods. >> >> >> On Fri, Aug 30, 2013 at 2:39 PM, taki <[email protected]> wrote: >> >>> 2013-08-29 14:07 időpontban Thomas Bruederli ezt írta: >>> >>> >>> Thanks for this! Here are some comments about your proposal: >>>> >>>> * PSR-2 compliance >>>> >>>> I generally agree to using PSR-2 even if there are some rules that >>>> personally I don't like. Especially the if/else newlines. >>>> >>> >>> There's a lots of inconsistency between PSR-1/2 and the current RC >>> Dev_Guidelines >>> (http://trac.roundcube.net/**wiki/Dev_Guidelines<http://trac.roundcube.net/wiki/Dev_Guidelines>) >>> eg. StudlyCaps and camelCase in class and method names. Anyone wants to >>> clarify the current rules? I want to create a ruleset for PHP_CodeSniffer. >>> >>> -- >>> Sandor Takacs >>> >>> ______________________________**_________________ >>> Roundcube Development discussion mailing list >>> [email protected] >>> http://lists.roundcube.net/**mailman/listinfo/dev<http://lists.roundcube.net/mailman/listinfo/dev> >>> >> >> >
_______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
