[ros-dev] [ros-diffs] [dgorbachev] 39422: Fix bug #4129 in CmpGetNameControlBlock().

[Zachary Gorden]

I agree with the requirement for the parenthesis, simply because it helps
separate the various conditions that are being tested for.  Even looking at
the code without braces, you should be questioning exactly what is going on
in there since you generally don't do assignments inside if statements.  The
fact that the compiler failed to catch it because of the parenthesis doesn't
excuse a programmer from not seeing the problem.  I personally would never
assume that a dev intended to do an assignment just because he or she put
parenthesis around such a statement, I would automatically assume they
messed up typing and left off a = in the check.

2009/2/16 Timo Kreuzer <timo.kreuzer at web.de>

>  I agree with Dmitry on that matter. The brackets are bad. They only hide
> possible bugs. I don't see any advantage. They don't add anything for the
> compiler nor do they add anything to readability. IMO it's easier to read
> with less braces.
>
> Timo
>
> Aleksey Bragin schrieb:
>
> Good, let's discuss it developers-wide then, and add a result into
> the (to become official) Coding Style Guidelines for kernel-mode code.
> The only thing I'm bothered with is to keep the style consistent
> across kernel (and drivers, where possible). And right now bracing
> arguments of && and || prevails.
>
> I'm eager to listen to other dev's opinion on that topic. You just
> showed one disadvantage of such method. Are there any advantages?
>
>
> WBR,
> Aleksey.
>
> On Feb 16, 2009, at 8:47 PM, Dmitry Gorbachev wrote:
>
>
>
>  No, it's just a matter of coding style used in the kernel.
>
>
>  What is a logical basis for adopting this particular rule?
> Sometimes it is
> not just a matter of preference.
>
> These parentheses are unnecessary for humans, and if they are not
> needed for
> compilers or some other tools, they are bad! Without them, the bug
> could be
> noticed earlier.
>
> Cheers,
> Dmitry
>
>
>  _______________________________________________
> Ros-dev mailing listRos-dev at reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20090216/76069d8e/attachment.html