-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
All,
This is a follow-up on point #5 from my post earlier this month entitled "TDE GIT thaw, build farm status, and future direction".
Codebase formatting. While this is not a major problem for the users I have been tripped up more than once by the fact that some portions of the codebase (twin among others) use a vastly different style of indentation and bracing, one that is (IMHO) extremely hard to read and/or modify. This in turn has therefore contributed to many "fix up prior commit" commits and/or outright regressions in GIT. I greatly prefer Stroustrup style formatting with hard tab indentation (no space or combined space/tab indents) and indented public/protected/private blocks. This style is highly legible, emphasizes the control flow, and produces a minimal number of non-whitespace difference lines when an if/else block is modified. All of the new code (thousands and thousands of lines of it) that I have contributed to TDE have been in this style. I have been toying with reformatting the entire TDE codebase in one large commit; if there are no objections I think this step could greatly improve both our development speed and the overall quality of the codebase; comments and discussion are welcome.
I would like to start converting over the codebase ASAP. I have an automated tool that will do this, but would like some feedback on the style to convert into as reformatting like this is a one-time operation that will not be repeated for the life of the TDE project.
As mentioned above I strongly prefer a modified Stroustrup style formatting. Is this acceptable to the other developers, and if not, what would you rather use and why?
Thanks!
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 12/31/2014 06:51 AM, Timothy Pearson wrote:
All,
This is a follow-up on point #5 from my post earlier this month entitled "TDE GIT thaw, build farm status, and future direction".
Codebase formatting. While this is not a major problem for the users I have been tripped up more than once by the fact that some portions of the codebase (twin among others) use a vastly different style of indentation and bracing, one that is (IMHO) extremely hard to read and/or modify. This in turn has therefore contributed to many "fix up prior commit" commits and/or outright regressions in GIT. I greatly prefer Stroustrup style formatting with hard tab indentation (no space or combined space/tab indents) and indented public/protected/private blocks. This style is highly legible, emphasizes the control flow, and produces a minimal number of non-whitespace difference lines when an if/else block is modified. All of the new code (thousands and thousands of lines of it) that I have contributed to TDE have been in this style. I have been toying with reformatting the entire TDE codebase in one large commit; if there are no objections I think this step could greatly improve both our development speed and the overall quality of the codebase; comments and discussion are welcome.
I would like to start converting over the codebase ASAP. I have an automated tool that will do this, but would like some feedback on the style to convert into as reformatting like this is a one-time operation that will not be repeated for the life of the TDE project.
As mentioned above I strongly prefer a modified Stroustrup style formatting. Is this acceptable to the other developers, and if not, what would you rather use and why?
Thanks!
Tim
Hi Tim, code reformatting is definitely something we have to do. I meant to come back with some style ideas/rules last week but other things got into the way. Can you give me a few more days (say until Monday) to come back with my thought? In the mean time, I think it would be useful if you share a small piece of code showing the code formatting that you are thinking about. Since the code reformatting is a "one time op", we should make sure we are all happy with the code style we choose. Obviously this will require some compromise from each of us, since every one has its own preferences about style.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On 12/31/2014 06:51 AM, Timothy Pearson wrote:
All,
This is a follow-up on point #5 from my post earlier this month entitled "TDE GIT thaw, build farm status, and future direction".
Codebase formatting. While this is not a major problem for the users I have been tripped up more than once by the fact that some portions of the codebase (twin among others) use a vastly different style of indentation and bracing, one that is (IMHO) extremely hard to read and/or modify. This in turn has therefore contributed to many "fix up prior commit" commits and/or outright regressions in GIT. I greatly prefer Stroustrup style formatting with hard tab indentation (no space or combined space/tab indents) and indented public/protected/private blocks. This style is highly legible, emphasizes the control flow, and produces a minimal number of non-whitespace difference lines when an if/else block is modified. All of the new code (thousands and thousands of lines of it) that I have contributed to TDE have been in this style. I have been toying with reformatting the entire TDE codebase in one large commit; if there are no objections I think this step could greatly improve both our development speed and the overall quality of the codebase; comments and discussion are welcome.
I would like to start converting over the codebase ASAP. I have an automated tool that will do this, but would like some feedback on the style to convert into as reformatting like this is a one-time operation that will not be repeated for the life of the TDE project.
As mentioned above I strongly prefer a modified Stroustrup style formatting. Is this acceptable to the other developers, and if not, what would you rather use and why?
Thanks!
Tim
Hi Tim, code reformatting is definitely something we have to do. I meant to come back with some style ideas/rules last week but other things got into the way. Can you give me a few more days (say until Monday) to come back with my thought? In the mean time, I think it would be useful if you share a small piece of code showing the code formatting that you are thinking about. Since the code reformatting is a "one time op", we should make sure we are all happy with the code style we choose. Obviously this will require some compromise from each of us, since every one has its own preferences about style.
Cheers Michele
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
Tim
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in
over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in
over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in
over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
1) style: I prefer broken parenthesis instead of attached ones 2) hard tabs: ok with that. But use the force-tab option 3) no indent-cases blocks, too much indentations. 4) indent preprocessor defines on multiple lines 5) the "--break-blocks" is somehow optional. I have included it, but even without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
I noticed on quick glance that at least one alternate styles snuck in
over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
- style: I prefer broken parenthesis instead of attached ones
- hard tabs: ok with that. But use the force-tab option
- no indent-cases blocks, too much indentations.
- indent preprocessor defines on multiple lines
- the "--break-blocks" is somehow optional. I have included it, but even
without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
Just one quick comment; I still need to carefully review your other suggestions and comment on them later:
Detached braces are a big problem for me, severely reducing code legibility. Is this something you are flexible on or is code like this:
void foo() { // Do stuff }
hard for you to read?
Thanks!
Tim
On Thursday 01 of January 2015 11:02:13 Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
> Yes, we can wait a few days for your input. :-) > > The vast majority of this file was written in the style I prefer: > https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdeha >rdwaredevices.cpp?id=f27e71dcb162e37234ea98570379f60f8afdd8ea
I noticed on quick glance that at least one alternate styles snuck in
> over time, so the revision ID specified in that link is an older > version without many of the changes that > introduced those alternate styles. > > I find it very easy to read on mutiple screens, on the Web and in > Kate, from small laptops up to my main > workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
- style: I prefer broken parenthesis instead of attached ones
- hard tabs: ok with that. But use the force-tab option
- no indent-cases blocks, too much indentations.
- indent preprocessor defines on multiple lines
- the "--break-blocks" is somehow optional. I have included it, but even
without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
Just one quick comment; I still need to carefully review your other suggestions and comment on them later:
Detached braces are a big problem for me, severely reducing code legibility. Is this something you are flexible on or is code like this:
void foo() { // Do stuff }
hard for you to read?
Thanks!
Tim
In this respect, my sympathy are for the Michele proposal.
For me parentheses at the end of the line are "invisible". For me, the better when I see both brackets incised in the same column than when losing at end of a line. When I need to quickly see the beginning of the block, easier to see clear bracket than "some" text as if, else, while, for, function name,... just something ambiguous.
Just my two cents.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<snip>
Just one quick comment; I still need to carefully review your other suggestions and comment on them later:
Detached braces are a big problem for me, severely reducing code legibility. Is this something you are flexible on or is code like this:
void foo() { // Do stuff }
hard for you to read?
Thanks!
Tim
In this respect, my sympathy are for the Michele proposal.
For me parentheses at the end of the line are "invisible". For me, the better when I see both brackets incised in the same column than when losing at end of a line. When I need to quickly see the beginning of the block, easier to see clear bracket than "some" text as if, else, while, for, function name,... just something ambiguous.
Just my two cents.
In my programming carrier I have worked with different styles with different people, so if needed I can adapt to a different style and in general I am flexible. Whatever consistent style is better than "no style". The "attached brackets" vs "detached brackets" styles are two "schools of thoughts", so no wonder that if someone is used to one way he will find the other one harder to read, at least until he gets used to it. Having said all that, Slavek's comments described exactly my view on the bracket point: brackets at the end of the line are harder to find when scrolling along long blocks.
I guess there is no easy solution, either we choose one way or the other. A possible way to mitigate the problem for the developers of the other school of thought could be the following (a little awkward but I haven't found anything better yet): 1) we create two (or more) style files and respective beautify files, for example one for attached brackets and one for detached brackets. The more options are in common between the two styles the better 2) we choose as "official style" the one most developers are happy with. 3) the developers of the other school can still use their style to edit code locally before committing using these steps: a) git pull b) beautify_to_the_style_I_like.sh c) edit, compile, test locally until happy d) beautify_to_TDE_official_style.sh e) commit
It's a little bit uncomfortable, but at least its a possible way of working with one's own favorite code style. Note that point d) should become mandatory for all developers before any commit, to make sure the code style is maintain over time.
Other ideas?
Cheers Michele
On Thursday 01 of January 2015 13:31:04 Michele Calgaro wrote:
- the developers of the other school can still use their style to
edit code locally before committing using these steps: a) git pull b) beautify_to_the_style_I_like.sh c) edit, compile, test locally until happy d) beautify_to_TDE_official_style.sh e) commit
For this I'll afraid that reformatting sometimes can cause unnecessary changes to the code just because of repeated reformatting. This could lead to unnecessarily hard to read commits.
-- Slávek
On Thursday 01 of January 2015 07:22:08 Michele Calgaro wrote:
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
Yes, we can wait a few days for your input. :-)
The vast majority of this file was written in the style I prefer: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehar dwaredevices.cpp?id=f27e71dcb162e37234ea98570379f60f8afdd8ea
I noticed on quick glance that at least one alternate styles snuck in
over time, so the revision ID specified in that link is an older version without many of the changes that introduced those alternate styles.
I find it very easy to read on mutiple screens, on the Web and in Kate, from small laptops up to my main workstation. Comments are of course welcome!
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the way they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
- style: I prefer broken parenthesis instead of attached ones
- hard tabs: ok with that. But use the force-tab option
- no indent-cases blocks, too much indentations.
- indent preprocessor defines on multiple lines
- the "--break-blocks" is somehow optional. I have included it, but even
without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
Only just for show I attach a style that I used in my projects.
As you can see, I'm used to small indentation => code did not run to the right side so quickly. I do not have infinitely wide screen :)
Unusually looking definition of function parameters is based from the days when it was not used automatic generation of documentation => description of the parameters was not in a separate documenting comment, but the definition is self-commenting. Simple symbols used in comments <=> mark parameters simultaneously input and output, <= mark output parameters and => mark input parameters. At the same time, I have kept the habit of the parameters order: at first 'i/o' parameters, then 'o' parameters and the last 'i' parameters.
One thing that might be useful for our common rules for TDE is - strictly habit always use braces - even in cases where the block is a single line.
As I said in the beginning - I attach it only as a demonstration of my habits. I am also flexible and ready to use the style that we will confirm as default TDE style.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Thursday 01 of January 2015 07:22:08 Michele Calgaro wrote:
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
> Yes, we can wait a few days for your input. :-) > > The vast majority of this file was written in the style I prefer: > https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehar >dwaredevices.cpp?id=f27e71dcb162e37234ea98570379f60f8afdd8ea
I noticed on quick glance that at least one alternate styles snuck in
> over time, so the revision ID specified in that link is an older > version without many of the changes that introduced those
alternate
> styles. > > I find it very easy to read on mutiple screens, on the Web and in > Kate, from small laptops up to my main workstation. Comments are
of
> course welcome!
If my vote still counts, I have only one request: please do not use
8
spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
Darrell
I prefer hard tabs, this way each developer can set the space the
way
they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
- style: I prefer broken parenthesis instead of attached ones
- hard tabs: ok with that. But use the force-tab option
- no indent-cases blocks, too much indentations.
- indent preprocessor defines on multiple lines
- the "--break-blocks" is somehow optional. I have included it, but
even without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
Only just for show I attach a style that I used in my projects.
As you can see, I'm used to small indentation => code did not run to the right side so quickly. I do not have infinitely wide screen :)
Unusually looking definition of function parameters is based from the days when it was not used automatic generation of documentation => description of the parameters was not in a separate documenting comment, but the definition is self-commenting. Simple symbols used in comments <=> mark parameters simultaneously input and output, <= mark output parameters and => mark input parameters. At the same time, I have kept the habit of the parameters order: at first 'i/o' parameters, then 'o' parameters and the last 'i' parameters.
One thing that might be useful for our common rules for TDE is - strictly habit always use braces - even in cases where the block is a single line.
As I said in the beginning - I attach it only as a demonstration of my habits. I am also flexible and ready to use the style that we will confirm as default TDE style.
-- Slávek
You are correct about always using braces; this I want to see strictly enforced.
Unfortunately those detached indented braces make this extremely hard for me to read. This looks similar to the style used in kwin?
In my experience even if the brace is "invisible" after an if the presence of a control statement plus indentation (and combined with the braces always used rule) are more than sufficient as replacement cues. In effect what I like about placing the brace at the end is that the control statement and brace form a single "statment"; i.e. my eye only has to jump one line to read the next chunk of control flow instead of having to jump two with the second containing a good bit of whitespace. That same whitespace causes my eye to sometimes miss the initial statement of the next code, forcing a retrack and often pushing something else out of working memory in the process--this is the main reason I tend to mess up the control flow in twin commits and have to go back to fix it.
If I were to excercise the power of the BDFL on this project and override the braces to the way I want to see them would this be a major problem?
Tim
On Thursday 01 of January 2015 21:43:08 Timothy Pearson wrote:
On Thursday 01 of January 2015 07:22:08 Michele Calgaro wrote:
On 01/01/2015 04:27 AM, Timothy Pearson wrote:
On 2014/12/31 02:13 PM, Timothy Pearson wrote:
>> Yes, we can wait a few days for your input. :-) >> >> The vast majority of this file was written in the style I prefer: >> https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tde >>har dwaredevices.cpp?id=f27e71dcb162e37234ea98570379f60f8afdd8ea
I noticed on quick glance that at least one alternate styles snuck in
>> over time, so the revision ID specified in that link is an older >> version without many of the changes that introduced those
alternate
>> styles. >> >> I find it very easy to read on mutiple screens, on the Web and in >> Kate, from small laptops up to my main workstation. Comments are
of
>> course welcome! > > If my vote still counts, I have only one request: please do not use
8
> spaces for tabs. I prefer only 2 spaces, but 4 is acceptable. > > Darrell
I prefer hard tabs, this way each developer can set the space the
way
they want to see it.
Tim
Tim, just wondering. What tool do you use to reformat existing code? Cheers Michele
AStyle. In fact I was working on this in late 2012: https://git.trinitydesktop.org/cgit/scripts/tree/astyle
Tim
Hi Tim, well, first of all Happy New Year.
I had a closed look at astyle and played around with it quite a while. I have attached an alternative option file, which generates code closer to my favorite style. These are just my preferences, it doesn't mean we need to use it exactly as it is. In particular the most important points are:
- style: I prefer broken parenthesis instead of attached ones
- hard tabs: ok with that. But use the force-tab option
- no indent-cases blocks, too much indentations.
- indent preprocessor defines on multiple lines
- the "--break-blocks" is somehow optional. I have included it, but
even without it will do. 6) --pad-oper, --pad-header, --unpad-paren: I prefer something like if (a == b) rather than if( a==b ) 7) "--delete-empty-lines" ok if "--break-blocks" is used
Everything else is quite minor.
I have also attached the outputs created using the script currently in GIT and mine. Don't bother about the code itself, it was just made up for testing.
Cheers Michele
Only just for show I attach a style that I used in my projects.
As you can see, I'm used to small indentation => code did not run to the right side so quickly. I do not have infinitely wide screen :)
Unusually looking definition of function parameters is based from the days when it was not used automatic generation of documentation => description of the parameters was not in a separate documenting comment, but the definition is self-commenting. Simple symbols used in comments <=> mark parameters simultaneously input and output, <= mark output parameters and => mark input parameters. At the same time, I have kept the habit of the parameters order: at first 'i/o' parameters, then 'o' parameters and the last 'i' parameters.
One thing that might be useful for our common rules for TDE is - strictly habit always use braces - even in cases where the block is a single line.
As I said in the beginning - I attach it only as a demonstration of my habits. I am also flexible and ready to use the style that we will confirm as default TDE style.
-- Slávek
You are correct about always using braces; this I want to see strictly enforced.
Unfortunately those detached indented braces make this extremely hard for me to read. This looks similar to the style used in kwin?
In my experience even if the brace is "invisible" after an if the presence of a control statement plus indentation (and combined with the braces always used rule) are more than sufficient as replacement cues. In effect what I like about placing the brace at the end is that the control statement and brace form a single "statment"; i.e. my eye only has to jump one line to read the next chunk of control flow instead of having to jump two with the second containing a good bit of whitespace. That same whitespace causes my eye to sometimes miss the initial statement of the next code, forcing a retrack and often pushing something else out of working memory in the process--this is the main reason I tend to mess up the control flow in twin commits and have to go back to fix it.
If I were to excercise the power of the BDFL on this project and override the braces to the way I want to see them would this be a major problem?
Tim
Wow, indentation in twin is yet another - I would say, very confusing - because the brackets are at the same level of indentation as the block, so is lost completely. Awful.
I am aware that the more popular now are brackets at the end of lines. And I, as well as Michele, earlier mentioned that we are flexibile and we have no problem adapt to it. In fact, it was enough for the pleasure to me knowing that along with Michele we have the same preference :)
But what would prefer a smaller indentation in the switch cases - as featured Michele. Unfortunately I do not know whether astyle can be set to such a manner. See attachment.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<snip>
Only just for show I attach a style that I used in my projects.
As you can see, I'm used to small indentation => code did not run to the right side so quickly. I do not have infinitely wide screen :)
I usually use spaces instead of tabs when coding on my own. Anyhow using hard tabs is a good solution for shared code: each developer can set the tab width to its own liking and he can be sure the indentation is maintained. For example I use tab width = 2, so the code does not get to the RHS so quickly. Only disadvantage of using hard tabs instead of spaces is that when opening the file in a text editor that does not support variable width tabs, the tab is usually 8 spaces and the code goes to the right very quickly.
Unusually looking definition of function parameters is based from the days when it was not used automatic generation of documentation => description of the parameters was not in a separate documenting comment, but the definition is self-commenting. Simple symbols used in comments <=> mark parameters simultaneously input and output, <= mark output parameters and => mark input parameters. At the same time, I have kept the habit of the parameters order: at first 'i/o' parameters, then 'o' parameters and the last 'i' parameters.
One thing that might be useful for our common rules for TDE is - strictly habit always use braces - even in cases where the block is a single line.
As I said in the beginning - I attach it only as a demonstration of my habits. I am also flexible and ready to use the style that we will confirm as default TDE style.
-- Slávek
You are correct about always using braces; this I want to see strictly enforced.
I also prefer to always use brackets, even for single line statements. We all agree on this, so good.
Unfortunately those detached indented braces make this extremely hard for me to read. This looks similar to the style used in kwin?
In my experience even if the brace is "invisible" after an if the presence of a control statement plus indentation (and combined with the braces always used rule) are more than sufficient as replacement cues. In effect what I like about placing the brace at the end is that the control statement and brace form a single "statment"; i.e. my eye only has to jump one line to read the next chunk of control flow instead of having to jump two with the second containing a good bit of whitespace. That same whitespace causes my eye to sometimes miss the initial statement of the next code, forcing a retrack and often pushing something else out of working memory in the process--this is the main reason I tend to mess up the control flow in twin commits and have to go back to fix it.
If I were to excercise the power of the BDFL on this project and override the braces to the way I want to see them would this be a major problem?
Tim
Wow, indentation in twin is yet another - I would say, very confusing - because the brackets are at the same level of indentation as the block, so is lost completely. Awful.
Funny enough, I also had to code for several years with twin indentation style. One thing that I can say for sure about styles is that no matter what style you use, if you use it long enough you get used to it and even what at first might have seem ugly, in the end becomes natural. twin style is a perfect example of that: at first I really disliked it, but after I got used to it, it was no longer a problem. Not my favorite style though.
I am aware that the more popular now are brackets at the end of lines. And I, as well as Michele, earlier mentioned that we are flexibile and we have no problem adapt to it. In fact, it was enough for the pleasure to me knowing that along with Michele we have the same preference :)
I am flexible, so up to the BDFL's decision.
But what would prefer a smaller indentation in the switch cases - as featured Michele. Unfortunately I do not know whether astyle can be set to such a manner. See attachment.
Yes, I think the indentation for case blocks that I proposed is more logical: the case blocks are indented as a normal block. Instead the style in GIT adds an extra indentation level, which is somehow counter-intuitive. Just for the sake of consistent indentation.
- the developers of the other school can still use their style to
edit code locally before committing using these steps: a) git pull b) beautify_to_the_style_I_like.sh c) edit, compile, test locally until happy d) beautify_to_TDE_official_style.sh e) commit
For this I'll afraid that reformatting sometimes can cause unnecessary changes to the code just because of repeated reformatting. This could lead to unnecessarily hard to read commits.
That was only a suggestion. I also thing it is awkward to work like that and just easier to adapt to a new style. I did some tests and as long as most options are the same in the two styles, it seems to be quite ok. Also IMO we have to use point d) before any commit to make sure the committed code follows the correct style (especially when adapting from another style, it is easy to inadvertently introduce some style mistakes). Alternatively, we can have an automated beautify task running regularly on GIT (for example once a week).
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
<snip>
Funny enough, I also had to code for several years with twin indentation style. One thing that I can say for sure about styles is that no matter what style you use, if you use it long enough you get used to it and even what at first might have seem ugly, in the end becomes natural. twin style is a perfect example of that: at first I really disliked it, but after I got used to it, it was no longer a problem. Not my favorite style though.
My personal study of these adaptation phenomena has led me to the conclusion that, in most cases, the "adaption" is more an automated hiding of an inefficient and/or error-prone style from the level of the programmer's conciousness. Basically it shows up to an outside observer as a slowing down of the programmer's work without his or her knowledge, similar to clunky computer interfaces slowing down common tasks without the user's knowledge or inefficient factory stations draining employee productivity. It can even manifest as a subtle almost subconcious dislike of working on the code without the programmer ever really becoming aware of why. This is something we want to avoid if at all possible, hence this discussion. :-)
Now of course there are cases where true adaption does take place, but there are limits on how far out the style can be from the programmer's natural expectations before this no longer holds. ;-)
I am aware that the more popular now are brackets at the end of lines. And I, as well as Michele, earlier mentioned that we are flexibile and we have no problem adapt to it. In fact, it was enough for the pleasure to me knowing that along with Michele we have the same preference :)
I am flexible, so up to the BDFL's decision.
But what would prefer a smaller indentation in the switch cases - as featured Michele. Unfortunately I do not know whether astyle can be set to such a manner. See attachment.
Yes, I think the indentation for case blocks that I proposed is more logical: the case blocks are indented as a normal block. Instead the style in GIT adds an extra indentation level, which is somehow counter-intuitive. Just for the sake of consistent indentation.
So, to be clear, this is what is desired?
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
My question is this: Say I have a long case statement (dozens of cases with subsequent processing blocks, enough to run off both vertical edges of my screen) and it's "conveniently" located in the middle of a large source file with other case blocks and "normal code" above and below it. With the style above I will have problems finding the end of the case block, which is why I started indenting them like this:
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
There are actually several instances of the pathological case described above in the TDE source tree right now, in the udev and network-manager interfaces among other locations, and I expect the number of these to grow as more DBUS-based system abstraction layers are forced on us (e.g. systemd, logind, and who knows what else down the line). Being able to easily say "yeah, I know what that case block does, get me to the next line of code after the case handler" by simply following the indentation proved quite valuable for me when writing the TDE hardware library.
Rebuttals welcome. :-)
That was only a suggestion. I also thing it is awkward to work like that and just easier to adapt to a new style. I did some tests and as long as most options are the same in the two styles, it seems to be quite ok. Also IMO we have to use point d) before any commit to make sure the committed code follows the correct style (especially when adapting from another style, it is easy to inadvertently introduce some style mistakes). Alternatively, we can have an automated beautify task running regularly on GIT (for example once a week).
I will definitely enforce the chosen style through an automated method; I'm not sure if I can practically hook into GIT for pre-commit as we have so many modules but I will be adding something to the server to make sure the style doesn't inadvertently "drift" over time.
This is the current consensus as far as I can tell: 1.) Every conditional uses braces 2.) Hard tabs 3.) Conditional indentation like so:
if (foo) { a=0; } else if (bar) { a=1; } else { a=2; }
We still need to discuss how to handle large chains of conditionals, e.g. these pathological cases: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Is the style shown there acceptable?
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
One other issue is the whitespace within conditional expressions. As you can see I'm fairly undecided on this as well, having used multiple styles already: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede... https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Given a choice I slightly prefer the style shown on line 2518; my only strong preference here is that I don't want to see any whitespace between two matched parenthesis: Correct: execute_something() Wrong: execute_something( )
Thoughts are welcome here as well.
Thanks!
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/09/2015 11:40 AM, Timothy Pearson wrote:
<snip>
So, to be clear, this is what is desired?
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
My question is this: Say I have a long case statement (dozens of cases with subsequent processing blocks, enough to run off both vertical edges of my screen) and it's "conveniently" located in the middle of a large source file with other case blocks and "normal code" above and below it. With the style above I will have problems finding the end of the case block, which is why I started indenting them like this:
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
I think what is desired is something like this:
do_something(); switch(foo) { case bar: a=1; break; case baz: { a=2; ...long case block... c=4; break; } case asd: a=3; break; default: a=0; } do_something_else();
The { and } in case blocks are not really needed and my preference would be not to use them there. If needed, they should be indented as any other block. The style in GIT adds an extra indentation level to those {-} case blocks, which is what Slavek and I were "complaining".
<snip> This is the current consensus as far as I can tell: 1.) Every conditional uses braces 2.) Hard tabs 3.) Conditional indentation like so:
if (foo) { a=0; } else if (bar) { a=1; } else { a=2; }
We still need to discuss how to handle large chains of conditionals, e.g. these pathological cases: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Is the style shown there acceptable?
My preference would be for breaking after the logical operator and either have no indentation or double indentation for the subsequent lines.
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
or
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
One other issue is the whitespace within conditional expressions. As you can see I'm fairly undecided on this as well, having used multiple styles already: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Given a choice I slightly prefer the style shown on line 2518; my only strong preference here is that I don't want to see any whitespace between two matched parenthesis: Correct: execute_something() Wrong: execute_something( )
Thoughts are welcome here as well.
Same as you, no spaces at the beginning and end parenthesis, i.e. line 2518 is better for me.
Also, I suggest to have a space between function parameters as in foo(par1, par2, par3, par4) instead of foo(par1,par2,par3,par4)
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/09/2015 11:40 AM, Timothy Pearson wrote:
<snip>
So, to be clear, this is what is desired?
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
My question is this: Say I have a long case statement (dozens of cases with subsequent processing blocks, enough to run off both vertical edges of my screen) and it's "conveniently" located in the middle of a large source file with other case blocks and "normal code" above and below it. With the style above I will have problems finding the end of the case block, which is why I started indenting them like this:
do_something(); switch(foo) { case bar: a=1; case baz: a=2; case asd: a=3; default: a=0; } do_something_else();
I think what is desired is something like this:
do_something(); switch(foo) { case bar: a=1; break; case baz: { a=2; ...long case block... c=4; break; } case asd: a=3; break; default: a=0; } do_something_else();
The { and } in case blocks are not really needed and my preference would be not to use them there. If needed, they should be indented as any other block. The style in GIT adds an extra indentation level to those {-} case blocks, which is what Slavek and I were "complaining".
Ah, OK, that is a valid complaint. The case style shown above is fine and we'll go with that.
My only remaining question then is should we also be forcing whitespace between each case block for legibility, something like this?
do_something(); switch(foo) { case bar: a=1; break;
case baz: { a=2; ...long case block... c=4; break; }
case asd: a=3; break;
default: a=0; } do_something_else();
<snip> This is the current consensus as far as I can tell: 1.) Every conditional uses braces 2.) Hard tabs 3.) Conditional indentation like so:
if (foo) { a=0; } else if (bar) { a=1; } else { a=2; }
We still need to discuss how to handle large chains of conditionals, e.g. these pathological cases: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Is the style shown there acceptable?
My preference would be for breaking after the logical operator and either have no indentation or double indentation for the subsequent lines.
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
or
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
I am curious as to why you find this more intuitive than having the logical operator before the comparison. Roughly translating to English the above style reads something like:
if the box is black AND <pause> the box is not square AND <pause> the sphere is purple OR the sphere is NOT PRESENT THEN
versus
if the box is black <pause> AND the box is not square <pause> AND the sphere is purple <pause> OR the sphere is NOT PRESENT <pause> THEN
You can see how in the latter style the relevant logical operator is stated first, then the expression, with all required information to understand the conditional contained on one line instead of spanning two lines. The latter is easier for me to grasp all of the conditions required in a large expression; the former requires a bit more effort.
It isn't a big deal either way for me, and I'd like Slavek's input before deciding, but I am curious as to the thought processes behind the suggested style. :-)
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is your opinion Slavek?
One other issue is the whitespace within conditional expressions. As you can see I'm fairly undecided on this as well, having used multiple styles already: https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
https://git.trinitydesktop.org/cgit/tdelibs/tree/tdecore/tdehw/tdehardwarede...
Given a choice I slightly prefer the style shown on line 2518; my only strong preference here is that I don't want to see any whitespace between two matched parenthesis: Correct: execute_something() Wrong: execute_something( )
Thoughts are welcome here as well.
Same as you, no spaces at the beginning and end parenthesis, i.e. line 2518 is better for me.
OK, we'll go with that then.
Also, I suggest to have a space between function parameters as in foo(par1, par2, par3, par4) instead of foo(par1,par2,par3,par4)
Good catch! Agreed.
As the number of finalized rules is steadily growing I have started an Etherpad here to codify them and keep track of where we are at: http://trinity.etherpad.trinitydesktop.org/87
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<snip>
My only remaining question then is should we also be forcing whitespace between each case block for legibility, something like this?
do_something(); switch(foo) { case bar: a=1; break;
case baz: { a=2; ...long case block... c=4; break; }
case asd: a=3; break;
default: a=0; } do_something_else();
Empty lines between cases makes reading a little easier IMO. Sounds like a good idea to me.
<snip>
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
or
if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & TDEDiskDeviceType::CDR) || (disktype & TDEDiskDeviceType::CDRW))
I am curious as to why you find this more intuitive than having the logical operator before the comparison. Roughly translating to English the above style reads something like:
if the box is black AND <pause> the box is not square AND <pause> the sphere is purple OR the sphere is NOT PRESENT THEN
versus
if the box is black <pause> AND the box is not square <pause> AND the sphere is purple <pause> OR the sphere is NOT PRESENT <pause> THEN
You can see how in the latter style the relevant logical operator is stated first, then the expression, with all required information to understand the conditional contained on one line instead of spanning two lines. The latter is easier for me to grasp all of the conditions required in a large expression; the former requires a bit more effort.
It isn't a big deal either way for me, and I'd like Slavek's input before deciding, but I am curious as to the thought processes behind the suggested style. :-)
This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons: 1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to continue reading the next line 2) logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a variable is a class member. TDE is a very wide variety of class member names. What is your opinion?
Another thing is class constructor parameter definition. Which one is better?
MyClass::MyClass(int i, char c, int *p, double d) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
<snip> > My only remaining question then is should we also be forcing whitespace > between each case block for legibility, > something like this? > > do_something(); switch(foo) { case bar: a=1; break; > > case baz: { a=2; ...long case block... c=4; break; } > > case asd: a=3; break; > > default: a=0; } do_something_else(); >
Empty lines between cases makes reading a little easier IMO. Sounds like a good idea to me.
OK, agreed and added to official spec.
<snip> >> if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & >> TDEDiskDeviceType::CDR) || (disktype & >> TDEDiskDeviceType::CDRW)) > >> or > >> if ((disktype & TDEDiskDeviceType::CDROM) || (disktype & >> TDEDiskDeviceType::CDR) || (disktype & >> TDEDiskDeviceType::CDRW)) > > I am curious as to why you find this more intuitive than having the > logical operator before the comparison. > Roughly translating to English the above style reads something like: > > if the box is black AND <pause> the box is not square AND <pause> the > sphere is purple OR the sphere is NOT PRESENT > THEN > > versus > > if the box is black <pause> AND the box is not square <pause> AND the > sphere is purple <pause> OR the sphere is NOT > PRESENT <pause> THEN > > You can see how in the latter style the relevant logical operator is > stated first, then the expression, with all > required information to understand the conditional contained on one line > instead of spanning two lines. The latter > is easier for me to grasp all of the conditions required in a large > expression; the former requires a bit more > effort. > > It isn't a big deal either way for me, and I'd like Slavek's input > before deciding, but I am curious as to the > thought processes behind the suggested style. :-) > This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons: 1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to continue reading the next line
Wouldn't the lack of a curly brace state the same thing, given our rules on curly braces?
- logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Point taken. However, I think we need to add a rule as well that states all conditionals must be enclosed in parenthesis; I have cleaned up so many compiler warnings and so much buggy code becase of lazy programmers in this respect that I don't want to see another unenclosed conditional. ;-)
If this rule is enforced, your second example becomes: if ((a == 3) && ((b == 5) || (c == 4) || ((d == 10) && (e == 20))))
which is a bit easier to read, but overall this style is still harder to read than your first example when more than one condition is present on one line. Perhaps we should allow both styles and simply state that the style providing "best legibility" should be used?
The number of long/complex ifs in the codebase are why I am insisting this be hammered out properly. :-) We haven't head from Slavek in a while so I guess we'll keep drawing up the specification and he can review it and comment when he has time.
Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a variable is a class member. TDE is a very wide variety of class member names. What is your opinion?
Yes! This is Hungarian notation for member variable scope, and should be strongly enforced. Added to spec for new code, though I don't think we can go back and fix this automatically.
Another thing is class constructor parameter definition. Which one is better?
MyClass::MyClass(int i, char c, int *p, double d) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
or
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
I prefer this: MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
and where a derived class is being created: MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
Is this acceptable?
I have also added a question to the Etherpad regarding loop control statement formatting; if you could respond to that I'd appreciate it.
Thanks!
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<big snip>
This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons: 1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to continue reading the next line
Wouldn't the lack of a curly brace state the same thing, given our rules on curly braces?
Yes, but an operator is more visible than a missing brace :-)
- logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Point taken. However, I think we need to add a rule as well that states all conditionals must be enclosed in parenthesis; I have cleaned up so many compiler warnings and so much buggy code becase of lazy programmers in this respect that I don't want to see another unenclosed conditional. ;-)
If this rule is enforced, your second example becomes: if ((a == 3) && ((b == 5) || (c == 4) || ((d == 10) && (e == 20))))
which is a bit easier to read, but overall this style is still harder to read than your first example when more than one condition is present on one line. Perhaps we should allow both styles and simply state that the style providing "best legibility" should be used?
The number of long/complex ifs in the codebase are why I am insisting this be hammered out properly. :-) We haven't head from Slavek in a while so I guess we'll keep drawing up the specification and he can review it and comment when he has time.
Forcing parenthesis everywhere can make code more difficult to read sometimes, as in:
if ((a == 3) || (b == 5) || (c == 4)) vs if (a == 3 || b == 5 || c == 4)
So I also favor the "best legibility" rule. Let's restate it as something like "the minimum number of parenthesis that clearly isolate a conditional logic block. Example:
Right: if (a == 3 || (b == 5 && d != 20) || c == 4) Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a variable is a class member. TDE is a very wide variety of class member names. What is your opinion?
Yes! This is Hungarian notation for member variable scope, and should be strongly enforced. Added to spec for new code, though I don't think we can go back and fix this automatically.
Another thing is class constructor parameter definition. Which one is better?
<style snip>
I prefer this: MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
and where a derived class is being created: MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
Is this acceptable?
If we use this style, for consistency I think the constructor of a derived class should be:
MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
since the "base block" is just another part of the class object, as any other member. My only concern is that with big classes, the list of members can be quite long and so requires some scrolling from the constructor definition line to the actual constructor body. I usually use this style:
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
which is somehow more compact, but I am fine with both versions.
I have also added a question to the Etherpad regarding loop control statement formatting; if you could respond to that I'd appreciate it.
Thanks!
Done. Also added a question about variable/function/class names.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<big snip>
This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons: 1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to continue reading the next line
Wouldn't the lack of a curly brace state the same thing, given our rules on curly braces?
Yes, but an operator is more visible than a missing brace :-)
- logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Point taken. However, I think we need to add a rule as well that states all conditionals must be enclosed in parenthesis; I have cleaned up so many compiler warnings and so much buggy code becase of lazy programmers in this respect that I don't want to see another unenclosed conditional. ;-)
If this rule is enforced, your second example becomes: if ((a == 3) && ((b == 5) || (c == 4) || ((d == 10) && (e == 20))))
which is a bit easier to read, but overall this style is still harder to read than your first example when more than one condition is present on one line. Perhaps we should allow both styles and simply state that the style providing "best legibility" should be used?
The number of long/complex ifs in the codebase are why I am insisting this be hammered out properly. :-) We haven't head from Slavek in a while so I guess we'll keep drawing up the specification and he can review it and comment when he has time.
Forcing parenthesis everywhere can make code more difficult to read sometimes, as in:
if ((a == 3) || (b == 5) || (c == 4)) vs if (a == 3 || b == 5 || c == 4)
So I also favor the "best legibility" rule. Let's restate it as something like "the minimum number of parenthesis that clearly isolate a conditional logic block. Example:
Right: if (a == 3 || (b == 5 && d != 20) || c == 4) Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
The problem with allowing these is that if I need to refactor the code to add in a single conditional I need to add parenthesis, which a.) is an additional source of error and b.) messes up the difference tracking making it hard for other developers to see what the functional change was. I think I'm going to override you on this one and force the parenthesis. ;-)
Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a variable is a class member. TDE is a very wide variety of class member names. What is your opinion?
Yes! This is Hungarian notation for member variable scope, and should be strongly enforced. Added to spec for new code, though I don't think we can go back and fix this automatically.
Another thing is class constructor parameter definition. Which one is better?
<style snip>
I prefer this: MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
and where a derived class is being created: MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
Is this acceptable?
If we use this style, for consistency I think the constructor of a derived class should be:
MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
since the "base block" is just another part of the class object, as any other member.
But the base class(es) are fundamentally different than the other members; I like the visual distinction on first glance. Slavek, what is your opinion here?
My only concern is that with big classes, the list of members can be quite long and so requires some scrolling from the constructor definition line to the actual constructor body. I usually use this style:
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
which is somehow more compact, but I am fine with both versions.
While that is more compact, it introduces a problem with maintainability. Say I need to add a new member variable, strongly associated with m_c. That changes the definition to:
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_cRel(c_r), m_p(p), m_d(d) { do_something(); }
which a.) required quite a bit of editing (enough to make me think twice about adding the new member variable!) and b.) now shows two lines as completely changed in the difference output. The less-compact style makes it easy to add the variable, and shows at a glance what changed in the difference output.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/13/2015 08:25 AM, Timothy Pearson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
<big snip>
This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons: 1) the operator at the end of the line tells me immediately that the conditional expression is not over and I need to continue reading the next line
Wouldn't the lack of a curly brace state the same thing, given our rules on curly braces?
Yes, but an operator is more visible than a missing brace :-)
- logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Point taken. However, I think we need to add a rule as well that states all conditionals must be enclosed in parenthesis; I have cleaned up so many compiler warnings and so much buggy code becase of lazy programmers in this respect that I don't want to see another unenclosed conditional. ;-)
If this rule is enforced, your second example becomes: if ((a == 3) && ((b == 5) || (c == 4) || ((d == 10) && (e == 20))))
which is a bit easier to read, but overall this style is still harder to read than your first example when more than one condition is present on one line. Perhaps we should allow both styles and simply state that the style providing "best legibility" should be used?
The number of long/complex ifs in the codebase are why I am insisting this be hammered out properly. :-) We haven't head from Slavek in a while so I guess we'll keep drawing up the specification and he can review it and comment when he has time.
Forcing parenthesis everywhere can make code more difficult to read sometimes, as in:
if ((a == 3) || (b == 5) || (c == 4)) vs if (a == 3 || b == 5 || c == 4)
So I also favor the "best legibility" rule. Let's restate it as something like "the minimum number of parenthesis that clearly isolate a conditional logic block. Example:
Right: if (a == 3 || (b == 5 && d != 20) || c == 4) Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
The problem with allowing these is that if I need to refactor the code to add in a single conditional I need to add parenthesis, which a.) is an additional source of error and b.) messes up the difference tracking making it hard for other developers to see what the functional change was. I think I'm going to override you on this one and force the parenthesis. ;-)
No problem, not a big deal.
Another thing is class/struct member names. I usually add an "m_" to every member, so I know immediately that a variable is a class member. TDE is a very wide variety of class member names. What is your opinion?
Yes! This is Hungarian notation for member variable scope, and should be strongly enforced. Added to spec for new code, though I don't think we can go back and fix this automatically.
Another thing is class constructor parameter definition. Which one is better?
<style snip>
I prefer this: MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
and where a derived class is being created: MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
Is this acceptable?
If we use this style, for consistency I think the constructor of a derived class should be:
MyClass::MyClass(int i, char c, int *p) : TQObject(), m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
since the "base block" is just another part of the class object, as any other member.
But the base class(es) are fundamentally different than the other members; I like the visual distinction on first glance. Slavek, what is your opinion here?
Up to you and Slavek, both ways are ok for me.
My only concern is that with big classes, the list of members can be quite long and so requires some scrolling from the constructor definition line to the actual constructor body. I usually use this style:
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_p(p), m_d(d) { do_something(); }
which is somehow more compact, but I am fine with both versions.
While that is more compact, it introduces a problem with maintainability. Say I need to add a new member variable, strongly associated with m_c. That changes the definition to:
MyClass::MyClass(int i, char c, int *p) : m_i(i), m_c(c), m_cRel(c_r), m_p(p), m_d(d) { do_something(); }
which a.) required quite a bit of editing (enough to make me think twice about adding the new member variable!) and b.) now shows two lines as completely changed in the difference output. The less-compact style makes it easy to add the variable, and shows at a glance what changed in the difference output.
ok, I see the point.
Cheers Michele
On Tuesday 13 of January 2015 00:25:15 Timothy Pearson wrote:
Forcing parenthesis everywhere can make code more difficult to read sometimes, as in:
if ((a == 3) || (b == 5) || (c == 4)) vs if (a == 3 || b == 5 || c == 4)
So I also favor the "best legibility" rule. Let's restate it as something like "the minimum number of parenthesis that clearly isolate a conditional logic block. Example:
Right: if (a == 3 || (b == 5 && d != 20) || c == 4) Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
The problem with allowing these is that if I need to refactor the code to add in a single conditional I need to add parenthesis, which a.) is an additional source of error and b.) messes up the difference tracking making it hard for other developers to see what the functional change was. I think I'm going to override you on this one and force the parenthesis. ;-)
Ok, I understand and accept.
On Sunday 11 of January 2015 22:20:50 Timothy Pearson wrote:
This is of course subjective and not a big deal for me as well (I have already worked with both style actually). Mostly two reasons:
- the operator at the end of the line tells me immediately that the
conditional expression is not over and I need to continue reading the next line
Wouldn't the lack of a curly brace state the same thing, given our rules on curly braces?
- logically easier to read complex statement. For example
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)))
rather than:
if (a == 3 && (b == 5 || c == 4
I find the second one more prone to misinterpretation, since the || in the 3rd row might look at the same level as the && in the second row at first sight. And in TDE I have seen some rather complex and long ifs :-) Just my 2 cents, let's see what Slavek thinks as well.
Point taken. However, I think we need to add a rule as well that states all conditionals must be enclosed in parenthesis; I have cleaned up so many compiler warnings and so much buggy code becase of lazy programmers in this respect that I don't want to see another unenclosed conditional. ;-) If this rule is enforced, your second example becomes: if ((a == 3) && ((b == 5) || (c == 4)
which is a bit easier to read, but overall this style is still harder to read than your first example when more than one condition is present on one line. Perhaps we should allow both styles and simply state that the style providing "best legibility" should be used?
The number of long/complex ifs in the codebase are why I am insisting this be hammered out properly. :-) We haven't head from Slavek in a while so I guess we'll keep drawing up the specification and he can review it and comment when he has time.
For me also are certainly more readable operators at the end of the line, rather than at beginning. The only case where I'm used to using the operators at the beginning of the line is sql where I use words operators (and, or, ...) instead of symbols.
By the way, in my usual style I'm used to indent brackets also in conditions, which from my perspective clarifies their nesting. For example:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)) && (f == 15 || g == 25)) { }
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)) && (f == 15 || g == 25)) { }
Forcing parenthesis everywhere can make code more difficult to read sometimes, as in:
if ((a == 3) || (b == 5) || (c == 4)) vs if (a == 3 || b == 5 || c == 4)
So I also favor the "best legibility" rule. Let's restate it as something like "the minimum number of parenthesis that clearly isolate a conditional logic block. Example:
Right: if (a == 3 || (b == 5 && d != 20) || c == 4) Wrong: if (a == 3 || b == 5 && d != 20 || c == 4)
In this I agree with Michele.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/17/2015 11:52 PM, Slávek Banko wrote:
By the way, in my usual style I'm used to indent brackets also in conditions, which from my perspective clarifies their nesting. For example:
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)) && (f == 15 || g == 25)) { }
if (a == 3 && (b == 5 || c == 4 || (d == 10 && e == 20)) && (f == 15 || g == 25)) { }
Good idea, makes the code easier to read. Cheers Michele
First of all: I was in earlier days very busy, so I did not manage to follow and respond to the debate on coding style. Now I will try gradually respond to individual discussed cases.
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Ah, OK, that is a valid complaint. The case style shown above is fine and we'll go with that.
My only remaining question then is should we also be forcing whitespace between each case block for legibility, something like this?
do_something(); switch(foo) { case bar: a=1; break;
case baz: { a=2; ...long case block... c=4; break; }
case asd: a=3; break;
default: a=0; } do_something_else();
Here I would like to advocate for the previously mentioned principle braces even where they are not required. By this I mean that each 'case' consider as block => each case should to have brackets, including 'default':
do_something(); switch(foo) { case bar: { a=1; break; }
case baz: { a=2; ...long case block... c=4; break; }
case asd: { a=3; break; }
default: { a=0; } } do_something_else();
The advantage is that regardless of the size of the 'case' is easily traceable beginning of the block => editor can be used to trace paired brackets. With this would also not need white space between each 'case'. By the way, I wont give white space anyway. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2015/01/17 11:30 PM, Slávek Banko wrote:
First of all: I was in earlier days very busy, so I did not manage to follow and respond to the debate on coding style. Now I will try gradually respond to individual discussed cases.
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Ah, OK, that is a valid complaint. The case style shown above is fine and we'll go with that.
My only remaining question then is should we also be forcing whitespace between each case block for legibility, something like this?
do_something(); switch(foo) { case bar: a=1; break;
case baz: { a=2; ...long case block... c=4; break; }
case asd: a=3; break;
default: a=0; } do_something_else();
Here I would like to advocate for the previously mentioned principle braces even where they are not required. By this I mean that each 'case' consider as block => each case should to have brackets, including 'default':
do_something(); switch(foo) { case bar: { a=1; break; }
case baz: { a=2; ...long case block... c=4; break; }
case asd: { a=3; break; }
default: { a=0; } } do_something_else();
The advantage is that regardless of the size of the 'case' is easily traceable beginning of the block => editor can be used to trace paired brackets. With this would also not need white space between each 'case'. By the way, I wont give white space anyway. :)
This is good for me too, I actually almost wanted to propose it myself :-) Cheers Michele
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is your opinion Slavek?
Yes, with spaces - in my view certainly readable.
On Saturday 17 of January 2015 15:59:19 Slávek Banko wrote:
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is your opinion Slavek?
Yes, with spaces - in my view certainly readable.
Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad. I prefer to continue the discussion here.
I would say that there already was a consensus regarding spaces in the assignments - ie "a = b + c" and already there was a consensus regarding spaces around operators in conditions such as if, while - ie "if (a == b)".
All was fine until we had a case of 'for'. At its core, it does not contain anything new - uses the assignment and uses conditions => for both there already was a consensus. So one would expect that there is no problem.
Michele proposed: for (i = 0; i < 1; i = i + 2) { }
advantage - is fully in line with already agreed practices disadvantage - are harder to distinguish the individual 'for' expressions
Tim proposed: for (i=0; i<1; i=i+2) { }
advantage - are well distinguishable individual 'for' expressions disadvantages - difficult to read individual 'for' expressions as such - is inconsistent with already agreed practices
I understand Tim's argument. But that we would either to 'for' give exemption from other rules - which does not sound too good, or we would have to change already agreed rules - which is even worse option. I really would not want to because of the 'for' reduce the readability of all other conditions and assignments.
But there is another thing - more complex 'for' where individual parts can contain more assignments and more conditions - in such cases Tim's argument will be less important - on the contrary will be greater problem reduced readability each expressions as such.
Therefore I have two proposals:
1) As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 2)) { }
2) More complex 'for' break into lines:
for ((i = iteratorInicialization(arg)); (i != iteratorEnd(arg)); (i = iteratorNext(arg))) { }
What do you think about that?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/18/2015 02:24 AM, Slávek Banko wrote:
On Saturday 17 of January 2015 15:59:19 Slávek Banko wrote:
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is your opinion Slavek?
Yes, with spaces - in my view certainly readable.
Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad. I prefer to continue the discussion here.
I would say that there already was a consensus regarding spaces in the assignments - ie "a = b + c" and already there was a consensus regarding spaces around operators in conditions such as if, while - ie "if (a == b)".
All was fine until we had a case of 'for'. At its core, it does not contain anything new - uses the assignment and uses conditions => for both there already was a consensus. So one would expect that there is no problem.
Michele proposed: for (i = 0; i < 1; i = i + 2) { }
advantage - is fully in line with already agreed practices disadvantage - are harder to distinguish the individual 'for' expressions
Tim proposed: for (i=0; i<1; i=i+2) { }
advantage - are well distinguishable individual 'for' expressions disadvantages - difficult to read individual 'for' expressions as such - is inconsistent with already agreed practices
I understand Tim's argument. But that we would either to 'for' give exemption from other rules - which does not sound too good, or we would have to change already agreed rules - which is even worse option. I really would not want to because of the 'for' reduce the readability of all other conditions and assignments.
But there is another thing - more complex 'for' where individual parts can contain more assignments and more conditions - in such cases Tim's argument will be less important - on the contrary will be greater problem reduced readability each expressions as such.
Therefore I have two proposals:
- As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 2)) { }
- More complex 'for' break into lines:
for ((i = iteratorInicialization(arg)); (i != iteratorEnd(arg)); (i = iteratorNext(arg))) { }
What do you think about that?
The excessive brackets are a possible solution, but on the other hand are a little "too excessive" IMO. What about the following ideas:
1) use two or three spaces to separate for statement expressions, as in:
for (i = 0; i < 1; i = i + 2) {
or
for (i = 0; i < 1; i = i + 2) {
This should be relatively easy to read, maintain all conventions and does not require excessive/superfluous parenthesis.
2) use one line for each for expression as in:
for (i = 0; i < 1; i = i + 2) {
I also thought more about bracket position and came up with the following idea which is a mix of Tim's favorite style and mine/Slavek's favorite style.
if (foo) { a = 0; b = 1; } else if (bar) { a = 1; b = 2; } else { a = 2; }
switch(foo) { case bar: { a = 1; break; } case baz: { a = 2; ...long case block... c = 4; break; } case asd: { a = 3; break; } default: { a = 0; } }
Basically, the only difference from Tim's style is that the opening bracket is detached and located in the following line, but the "space location" of the lines of code remains the same (no additional lines required only for the opening bracket). At the same time the opening and closing brackets are aligned, making easy to detect the beginning and ending of a block. What do you think? This is actually the first style I ever used many many many years ago :-)
Cheers Michele
On Sunday 18 of January 2015 03:58:34 Michele Calgaro wrote:
On 01/18/2015 02:24 AM, Slávek Banko wrote:
On Saturday 17 of January 2015 15:59:19 Slávek Banko wrote:
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
Also on the docket are how to handle simple variable assignments; there are several ways I've seen: a=2; a = 2; a= 2; a =2;
I'm fairly undecided on this. For consistency with larger statements "a = 1;" should probably be used but it seems such a waste of space compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the first way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become confusing with long and complex ones such as: if ((a = 2) && (++b != (c + (x * y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is your opinion Slavek?
Yes, with spaces - in my view certainly readable.
Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad. I prefer to continue the discussion here.
I would say that there already was a consensus regarding spaces in the assignments - ie "a = b + c" and already there was a consensus regarding spaces around operators in conditions such as if, while - ie "if (a == b)".
All was fine until we had a case of 'for'. At its core, it does not contain anything new - uses the assignment and uses conditions => for both there already was a consensus. So one would expect that there is no problem.
Michele proposed: for (i = 0; i < 1; i = i + 2) { }
advantage - is fully in line with already agreed practices disadvantage - are harder to distinguish the individual 'for' expressions
Tim proposed: for (i=0; i<1; i=i+2) { }
advantage - are well distinguishable individual 'for' expressions disadvantages - difficult to read individual 'for' expressions as such - is inconsistent with already agreed practices
I understand Tim's argument. But that we would either to 'for' give exemption from other rules - which does not sound too good, or we would have to change already agreed rules - which is even worse option. I really would not want to because of the 'for' reduce the readability of all other conditions and assignments.
But there is another thing - more complex 'for' where individual parts can contain more assignments and more conditions - in such cases Tim's argument will be less important - on the contrary will be greater problem reduced readability each expressions as such.
Therefore I have two proposals:
- As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 2)) { }
- More complex 'for' break into lines:
for ((i = iteratorInicialization(arg)); (i != iteratorEnd(arg)); (i = iteratorNext(arg))) { }
What do you think about that?
The excessive brackets are a possible solution, but on the other hand are a little "too excessive" IMO. What about the following ideas:
- use two or three spaces to separate for statement expressions, as in:
for (i = 0; i < 1; i = i + 2) {
or
for (i = 0; i < 1; i = i + 2) {
This should be relatively easy to read, maintain all conventions and does not require excessive/superfluous parenthesis.
Yeah, it looks good! Simple and clearly visible. Two spaces seem to me to be sufficient.
- use one line for each for expression as in:
for (i = 0; i < 1; i = i + 2) {
I have no objection to any of these methods.
I also thought more about bracket position and came up with the following idea which is a mix of Tim's favorite style and mine/Slavek's favorite style.
if (foo) { a = 0; b = 1; } else if (bar) { a = 1; b = 2; } else { a = 2; } switch(foo) { case bar: { a = 1; break; } case baz: { a = 2; ...long case block... c = 4; break; } case asd: { a = 3; break; } default: { a = 0; } }Basically, the only difference from Tim's style is that the opening bracket is detached and located in the following line, but the "space location" of the lines of code remains the same (no additional lines required only for the opening bracket). At the same time the opening and closing brackets are aligned, making easy to detect the beginning and ending of a block. What do you think? This is actually the first style I ever used many many many years ago :-)
Cheers Michele
Opening brace is on the front of the line, but its good visibility deteriorates text followed brace on the same line. Although the style is very compact, it seems to me less readable.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Sunday 18 of January 2015 03:58:34 Michele Calgaro wrote:
On 01/18/2015 02:24 AM, Slávek Banko wrote:
On Saturday 17 of January 2015 15:59:19 Slávek Banko wrote:
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
> Also on the docket are how to handle simple variable assignments; > there are several ways I've seen: a=2; a = 2; a= 2; a =2; > > I'm fairly undecided on this. For consistency with larger
statements
> "a = 1;" should probably be used but it seems such a waste of
space
> compared with "a=1;". Thoughts?
Both "a=1" and "a = 1" are fine for me. For long time I used the
first
way, but in the last couple of years I switched ti the second one: usually more readable for simple expressions but can become
confusing
with long and complex ones such as: if ((a = 2) && (++b != (c + (x
y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is
your
opinion Slavek?
Yes, with spaces - in my view certainly readable.
Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad. I prefer to continue the discussion here.
I would say that there already was a consensus regarding spaces in the assignments - ie "a = b + c" and already there was a consensus
regarding
spaces around operators in conditions such as if, while - ie "if (a == b)".
All was fine until we had a case of 'for'. At its core, it does not contain anything new - uses the assignment and uses conditions => for both there already was a consensus. So one would expect that there is
no
problem.
Michele proposed: for (i = 0; i < 1; i = i + 2) { }
advantage - is fully in line with already agreed practices
disadvantage -
are harder to distinguish the individual 'for' expressions
Tim proposed: for (i=0; i<1; i=i+2) { }
advantage - are well distinguishable individual 'for' expressions disadvantages - difficult to read individual 'for' expressions as such
is inconsistent with already agreed practices
I understand Tim's argument. But that we would either to 'for' give exemption from other rules - which does not sound too good, or we
would
have to change already agreed rules - which is even worse option. I really would not want to because of the 'for' reduce the readability
of
all other conditions and assignments.
But there is another thing - more complex 'for' where individual parts can contain more assignments and more conditions - in such cases Tim's argument will be less important - on the contrary will be greater
problem
reduced readability each expressions as such.
Therefore I have two proposals:
- As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 2)) { }
- More complex 'for' break into lines:
for ((i = iteratorInicialization(arg)); (i != iteratorEnd(arg)); (i = iteratorNext(arg))) { }
What do you think about that?
The excessive brackets are a possible solution, but on the other hand are a little "too excessive" IMO. What about the following ideas:
- use two or three spaces to separate for statement expressions, as in:
for (i = 0; i < 1; i = i + 2) {
or
for (i = 0; i < 1; i = i + 2) {
This should be relatively easy to read, maintain all conventions and does not require excessive/superfluous parenthesis.
<snip>
Sorry to be the odd one out here but that is rather difficult for me to read in addition to consuming a (IMHO) ridiculous amount of horizontal screen space. I understand the rationale, but now picture that statement in a sea of code--the eye will tend to scan right past it making determination of indent level difficult among other issues. Also, I have never seen this style in any other major project; please correct me if I am wrong. :-)
I still need to go over this thread and respond to the other messages, but haven't had much time lately.
Tim
Dne út 20. ledna 2015 Timothy Pearson napsal(a):
On Sunday 18 of January 2015 03:58:34 Michele Calgaro wrote:
On 01/18/2015 02:24 AM, Slávek Banko wrote:
On Saturday 17 of January 2015 15:59:19 Slávek Banko wrote:
On Friday 09 of January 2015 23:33:01 Timothy Pearson wrote:
>> Also on the docket are how to handle simple variable assignments; >> there are several ways I've seen: a=2; a = 2; a= 2; a =2; >> >> I'm fairly undecided on this. For consistency with larger
statements
>> "a = 1;" should probably be used but it seems such a waste of
space
>> compared with "a=1;". Thoughts? > > Both "a=1" and "a = 1" are fine for me. For long time I used the
first
> way, but in the last couple of years I switched ti the second one: > usually more readable for simple expressions but can become
confusing
> with long and complex ones such as: if ((a = 2) && (++b != (c + (x
> y) / f(q,w,e)))) Choice is up to you and Slavek.
I'm going to lean towards forcing spaces for consistency. What is
your
opinion Slavek?
Yes, with spaces - in my view certainly readable.
Wow, now I noticed a great debate about the spaces / no-spaces on Ehterpad. I prefer to continue the discussion here.
I would say that there already was a consensus regarding spaces in the assignments - ie "a = b + c" and already there was a consensus
regarding
spaces around operators in conditions such as if, while - ie "if (a == b)".
All was fine until we had a case of 'for'. At its core, it does not contain anything new - uses the assignment and uses conditions => for both there already was a consensus. So one would expect that there is
no
problem.
Michele proposed: for (i = 0; i < 1; i = i + 2) { }
advantage - is fully in line with already agreed practices
disadvantage -
are harder to distinguish the individual 'for' expressions
Tim proposed: for (i=0; i<1; i=i+2) { }
advantage - are well distinguishable individual 'for' expressions disadvantages - difficult to read individual 'for' expressions as such
is inconsistent with already agreed practices
I understand Tim's argument. But that we would either to 'for' give exemption from other rules - which does not sound too good, or we
would
have to change already agreed rules - which is even worse option. I really would not want to because of the 'for' reduce the readability
of
all other conditions and assignments.
But there is another thing - more complex 'for' where individual parts can contain more assignments and more conditions - in such cases Tim's argument will be less important - on the contrary will be greater
problem
reduced readability each expressions as such.
Therefore I have two proposals:
- As with the 'if' use 'excessive' brackets:
for ((i = 0); (i < 1); (i = i + 2)) { }
- More complex 'for' break into lines:
for ((i = iteratorInicialization(arg)); (i != iteratorEnd(arg)); (i = iteratorNext(arg))) { }
What do you think about that?
The excessive brackets are a possible solution, but on the other hand are a little "too excessive" IMO. What about the following ideas:
- use two or three spaces to separate for statement expressions, as in:
for (i = 0; i < 1; i = i + 2) {
or
for (i = 0; i < 1; i = i + 2) {
This should be relatively easy to read, maintain all conventions and does not require excessive/superfluous parenthesis.
<snip>
Sorry to be the odd one out here but that is rather difficult for me to read in addition to consuming a (IMHO) ridiculous amount of horizontal screen space. I understand the rationale, but now picture that statement in a sea of code--the eye will tend to scan right past it making determination of indent level difficult among other issues. Also, I have never seen this style in any other major project; please correct me if I am wrong. :-)
I still need to go over this thread and respond to the other messages, but haven't had much time lately.
Tim
Two spaces seem to me sufficient to good readability, while there was no violated clarity.
Writing assignments and conditions in the 'for' without spaces results in inconsistence style with herself. Or, if you propose to remove spaces in assignments and conditions in all code, will make hard to read all code.
For example - without spaces it simply disgust:
for (x=1,y=5; x<10&&y>0; x++,y--) { }
with spaces It's not beautiful, but at least readable:
for (x = 1, y = 5; x < 10 && y > 0; x++, y--) { }
Therefore, the use of two spaces seems to me the least painful. Just my two cents.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 01/21/2015 01:53 AM, Slávek Banko wrote:
Two spaces seem to me sufficient to good readability, while there was no violated clarity.
Writing assignments and conditions in the 'for' without spaces results in inconsistence style with herself. Or, if you propose to remove spaces in assignments and conditions in all code, will make hard to read all code.
For example - without spaces it simply disgust:
for (x=1,y=5; x<10&&y>0; x++,y--) { }
with spaces It's not beautiful, but at least readable:
for (x = 1, y = 5; x < 10 && y > 0; x++, y--) { }
Therefore, the use of two spaces seems to me the least painful. Just my two cents.
I also think the second is more readable than the first. Alternatively we can go for
for (x = 1, y = 5; x < 10 && y > 0; x++, y--)
although it is a waste of vertical space IMO.
cheers Michele
On Friday 09 of January 2015 03:40:45 Timothy Pearson wrote:
This is the current consensus as far as I can tell: 1.) Every conditional uses braces 2.) Hard tabs 3.) Conditional indentation like so:
if (foo) { a=0; } else if (bar) { a=1; } else { a=2; }
Incidentally, the 'else' is block like everyone other, so it "should have" their own brackets and indentation:
if (foo) { a=0; } else { if (bar) { a=1; } else { a=2; } }
I understand that in cases of use strictly as 'elseif' is acceptable to omit the brackets. However, only I'm not sure if complicated cases are a source of compiler warnings 'ambiguous else'.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2014/12/31 01:11 PM, Darrell wrote:
If my vote still counts, I have only one request: please do not use 8 spaces for tabs. I prefer only 2 spaces, but 4 is acceptable.
I do not see any reason why your vote should not count. We may have different views on different things, but we are all here for the common goal of improving TDE.
Cheers Michele
-
Darrell -
Michele Calgaro -
Slávek Banko -
Timothy Pearson