Hey guys - thanks for getting back to me.

Alright, so brackets on a newline for if/else are decided. Will put that in the next PR update round.

> On the one hand you suggest that variable assignments and such should be torn apart with empty lines in between for better readability and on the other hand you don't accept our way to visually separate if/else blocks by moving the elseif/else statement to a new line?

Of course I didn't mean to imply that code should be pulled apart as far as possible! ;-) Those are really two different things and while I have my opinions about it, I absolutely respect that you have your own way. As I've said before - I can only make suggestions, you have made your decision and I have no problem going with it. Just wanted to make sure I state my case as clearly as possible.

> Yes, it might not fit the PSR-2 guidelines but come on, if somebody is unable to read our code because of that, he/she would not qualify as a useful contributor to Roundcube anyways.

Well, I agree with that. I don't think people wouldn't be able to read the code, though, just that they might stumble over it. There is usually only so much stumbling that developers are able to cope with until they bail out of the decision to help out. Our kin tend to be headstrong beasts ;-)

> I tend to say no on this. But again, I'd like to hear others speaking up for or against single exit points. For me these are like GOTO commands.

I don't think that's a fair comparison, but I do see your point. I will try to stay away from changes like that for now.

> I previously tried to give a limit of 20 lines for if/else blocks. But that was just a wild estimation without looking at specific examples.

Yeah, I would say that limits like that aren't useful. I actually heard a story that somebody once put out a mantra that functions shouldn't be longer than 10 lines or something... Restrictions like that only get you a small bit of the way and then you end up with spaghetti code. As per usual, domain logic requirements soon make you regret decisions like that ;-)

In case of the if/else stuff, I would put my money on better encapsulation of the functionality into the individual domain objects to be the biggest reduction in code, eventually. For example - have checks against an objects properties within a function in that object, not in an if statement in another object or class.

> Thanks a lot for your patience in discussing this though!

My pleasure. This is a new experience for me as well and it has been very interesting so far!

(Although I secretly hope that going with spaces vs. tabs and brackets on a newline will buy me some leverage later on :-P )

> I'd add that I prefer function() { over function(){

Yup, got that ;-)

----------

Alright! I'm currently a bit swamped with my actual work-work, but I will try to get at least one of the PRs cleaned up to the latest specs this week.

If there is anything else you want to discuss or add, just let me know.

-David


On Tue, Sep 10, 2013 at 7:35 PM, A.L.E.C <alec@alec.pl> wrote:
On 09/06/2013 01:52 PM, Thomas Bruederli wrote:
> * Javascript: opening brace for anonymous functions are on the same
> line. No space between 'function' and brackets.

I'd add that I prefer

function() {

over

function(){

--
Aleksander 'A.L.E.C' Machniak
LAN Management System Developer [http://lms.org.pl]
Roundcube Webmail Developer  [http://roundcube.net]
---------------------------------------------------
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl
_______________________________________________
Roundcube Development discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev