I just recently [Posted a Review Question](https://codereview.stackexchange.com/questions/134816/custom-struct-design-range/134877#134877) and got some fantastic feedback. Exactly the point of this site.

Although IMO I processed 3 separate 'types' of review points.

1. You Missed X, (In my case an accidental public set on an immutable type)
2. a better approach might be (in my case, pre-computing some return results. )
3. Style choices, In my case omitting single-line braces/screaming cap consts

Now, I am not saying design reviews are bad. it is a discussion point and all sides should be heard, leads to a better overall understanding of design for everyone involved,but....

I like to consider myself somewhat experienced. I have quite a lot of years of practical development under my belt and for one reason or another I have settled on a design choice that does not always 100% match the document standards, as does everyone.

And even though no hard is intended it starts to become frustrating, bordering on condescending when you are repeatedly corrected on something you choose to do. When your decision is 'wrong'.

I think reviewing usability issues, ways to better adhere to design principles, code clarity issues in general great.

### Example:

I chose a nested ternary. In fact the only one In my entire programming career.
Given the implicit correlation between Start and End conceptually I believe

```
public static int AsClamped(int index, int start, int end)
{
    return index < start ? start 
         : index > end ? end 
         : index;
}

```

does not need to be split into a separate if statement, as I would do in 90% of similar cases.  

Now, that is an unpopular choice and I expected to be challenged on it…

but lets say, when I have a Fail-Early condition, invalid arguments, incompatible configuration, e.g a one line `if(cantGoAnyFurther())` scenario I always choose to forgo the brackets. it is unneccessary weight to what is, by design a quick, initial contract exit condition e.g

```
 if (percent <= 0 || percent > 100)
    throw new ArgumentOutOfRangeException("P...");

```

or

```
  if (!items.HasRange())
     return Enumerable.Empty<T>();

```

Clearly, those are design choices. Not mistakes, not even some major slap in the face of convention. I simply disagree, again same with screaming caps.

### My Point

We should differentiate review points between

* "you seem to be lacking an understanding in X"
* "you might have missed Y"
* "There is an X out there that simplifies...."

And the case of

> 
> * "The style choices you display do not meet convention".
> 
> 
> 

This is not a personal rant, I honestly think elements of reviews of something clearly not egregious or of potentially a chosen style or opinion should be pointed out with a proviso, something along the lines of.

> 
> "regarding a few style choice. the prevailing standard is:"
> 
> 
> * ...
> * ...
> 
> 
> 

A marked differentiation for newcomers between what is actually wrong vs what is different.

Thoughts?

**EDIT**

It seems the innocuous example I chose is surprisingly divisive. (not using single line brackets)

So while we hash that point out in the comments I do want to point out the question (I hope) is still a valid one.

Should there be a precedent set for separating stylistic choices that do not improve efficiency, adherence to solid/other design principles; and those that belong in a style guide?