try/catch idiom in std.datetime

Walter Bright newshound2 at digitalmars.com
Thu Nov 21 07:03:57 PST 2013


On 11/20/2013 10:35 PM, Jonathan M Davis wrote:
> Definitely, but almost all arguments over coding style seem to be very
> subjective even when some people try and claim that some of the issues are
> objective.

I've run across actual research on aspects of this now and then, and real 
measurable statistics show one way is better than another (better meaning 
produces fewer perceptual mistakes).

It's not dissimilar to A/B testing often done on web shopping pages.


> Most style choices which are objectively bad don't even ever get
> made precisely because they're objectively bad. There are of course
> exceptions, but I've rarely seen style arguments that are actually objective,
> and it's not uncommon to have people with drastically different opinions as to
> what looks good and who think that it should be obvious to everyone that what
> they think looks good looks good and that the other style looks horrible.

Just because A/B testing isn't done doesn't mean it's subjective.


> And I've run into plenty of cases where one developer thinks that a particular
> coding style is much easier to read, which is in complete contrast with what
> another developer thought was legible (how many parens to use and where being
> a prime example of that). So, it at least almost always seems like what's
> considered be a good, legible style is very subjective.

I bet if testing was done on it, a clear difference would emerge.

Just because two developers argue about it doesn't make it subjective. For 
example, we can both argue about where a program is expending its time, and we 
can both be wrong if we actually profile it and see.

The way humans perceive information is not random. Human factors engineering is 
not junk science. There's a reason lower case letters exist, it is not merely 
personal preference. It's objectively easier to read.


More information about the Digitalmars-d mailing list