> Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend e

> Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend effort on making code more readable. Winner winner, chicken dinner. Some of these things COULD one day be facts, but essentially no one has done the research to determine the fact form of the opinion. "In code of type X maintained like Y, structure Z has been identified to cause a higher defect rate and increased lifetime maintenance costs compared to ZZ" could be a true fact, but seldom do we have any results from rigorous study. Consistency certainly appears very useful, so appealing to some authorities opinion just to get a consistent outcome is probably a reasonable thing to do in many cases. Unfortunately, many people argue for these opinions by first confusing them for facts and defending them as such. We'd often be better off-- in matters of code style or similar-- if teams were more ready to use and accept arguments of the form "that as far as anyone knows option X is at least as good, objectively speaking, as anything other option and for consistency sake we might as well adopt it since {our industry, our team's most prolific reviewer, our existing codebase, etc.} prefers it".