Breaking Long Lines

Gedare Bloom gedare at rtems.org
Wed Nov 11 16:24:32 UTC 2020


On Tue, Nov 10, 2020 at 5:08 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 10/11/20 6:38 pm, Thomas Doerfler wrote:
> > Hi,
> >
> > Am 10.11.20 um 06:33 schrieb Chris Johns:
> >> On 9/11/20 5:50 pm, Sebastian Huber wrote:
> >>> On 09/11/2020 01:52, Chris Johns wrote:
> >>>
> >>>> On 6/11/20 7:11 pm, Sebastian Huber wrote:
> > ...
> >>>>
> >>>>   Avoid excess parentheses. Learn the operator precedence. rules.
> >>>
> >>> Yes, and I think this is a good rule.
> >>
> >> I am not sure it is a good rule and workable. Using it to handle indents is an
> >> example of it breaking down. The ability to control an indent is a long held
> >> tradition and editors like Emacs are designed to handle it yet it is not clear
> >> if it is OK under this rule.
> >>
> >
> > I tried not to jump in for more than 24 hours.
>
> :)
>
> > But now I want to drop in
> > my opinion. What is the whole purpose of a style guide? Is it to have a
> > nice looking code layout, neat an tidy like a ideal front garden, or is
> > it about readability/accessibility? We could write the whole of a C
> > module into one line and it could work anyway, so what about a style guide?
>
> We need something and I like what we have. It is a nice balance. I think some
> parts of the guide deal with issues that appear over time. We also now have
> better compiler checking these days, eg missing break statements, unused
> variables, etc, and other things that safety people like such as always have
> braces with nesting blocks.
>
> > IMHO it should improve readability and understanding of what goes on in
> > a certain module. The code should be readable and understandable not
> > only for highly experienced C programmers, but also for newbies (if they
> > tr<y hard enough).
>
> Yes. My concern is about rules that are worded in a way make them difficult to
> interpret and apply making them ineffectual.
>
> > Now back to paranthesis: Since we are very frugal with comments, we
> > should at least make complex expressions easier to read by structuring
> > them, where convenient, with parenthesis where it improves readability.
>
> I agree.
>
> > An alternative rule like "Learn the operator precedence" could lead to a
> > similar sentence "Learn C block structure" to eliminate any code
> > indentation rules, because these rules have the ONLY purpose to make the
> > underlying code block structure easier to visualize and comprehend.
>
> Yes I agree.
>
> > So: my counter-rule would be "use paranthesis if you think it makes an
> > expression easier to understand".
>
> Nice. This is guide that does not paint itself into a corner.

Giving some flexibility on additional parens is fine with me. This
kind of rule is oriented more toward students/beginners anyway, who
btw should still learn operator precedence.

patch please ;)

>
> Thanks
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list