[sbarre]

A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome.

Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own.

So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level).

For example, "go fmt" exists for a reason.

[Silhouette]

Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own.

If your own in-house developers, with full knowledge of the nature of their project and the kinds of requirements they're trying to meet, and with full control over their choice of tools and standards, really can't ever do better than some external organisation that is building a generic tool to cater to generic requirements and writing to general coding standards, then you should probably question the competence of your in-house developers.

This is not to say you shouldn't use existing material from outside your organisation if it's a good enough fit for what you're doing and saves time or otherwise has some tangible benefits, of course. However, your in-house team will normally have a huge advantage in terms of knowing specifics compared to almost any external equivalent. This is true whether we're talking about frameworks, coding standards, tools, or almost anything else used in programming.

The meme that anything written by a larger group of people outside your organisation is somehow inherently superior for your purposes to anything you could write in-house, and that any reluctance to use those external resources is inherently a case of NIH syndrome, just doesn't make any sense to me. There is no logical reason to believe it should be true since you're almost never comparing like with like, and I see very little empirical evidence that it is true in practice either, assuming reasonably competent and experienced in-house developers.

[mbrutsch]

> naively doing everything your own personal way (including at the team/company level).

You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.

[sbarre]

I actually upvoted you, for the record. But you drew a distinction between "in-house standards" and "the framework's standards" (which are by definition probably taken from widely adopted standards).

If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)

[mbrutsch]

> I actually upvoted you, for the record.

That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points.

> But you drew a distinction between "in-house standards" and "the framework's standards"

One is used in-house for all things relevant, one applies to a framework. In that, they are distinct.

> (which are by definition probably taken from widely adopted standards).

Probably.

> If you were implying that those two things might be identical then you did a bad job of conveying that.

sigh. Two things can be true at the same time. I give up.

[sbarre]

It's always possible to craft an anecdotal argument to disprove a generalized statement. We were obviously dealing in apples and oranges here..

I was making a generalized statement that likely applies to a large number of places (but indeed not all places), and you were providing a specific but not really comparable counter-point in return.

So yes, we were both right, but then again I ask "why reply?" if you're not replying in a similar context.

That's like me saying "the oceans are vast and dangerous" and you saying "but a pond is relatively safe"... You're technically correct, but what does it have to do with my initial statement?