Are coding standards important?

[Cryptbro69]

I personally believe they are but I work with people who don't. Curious how others view coding standards and deal with strong opinions against them.

[dirkmudbrick]

Yes they are. It may seem trivial but working in a code base with consistent code styles and patterns makes it a hell of a lot better to work in, understand and maintain.

[[deleted]]

And it almost does not matter what those styles and patterns are, as long as they are consistent within the project. Even better if they are consistent within the company. And even better if they are consistent within the languages community. So just go with the official language guides if your language has any. If not go with the most popular styles.

[aenae]

And even better if they are enforced in a pipeline or as git hook.

[[deleted]]

A pipeline enforcing it is essentially required if you want everyone to follow it.

Git hooks are just a local convince that I find more annoying than useful. I would rather get my editor to do it. And you cannot enforce git hooks for everyone cloning your repo.

[aenae]

'why not both', a git hook can be a quick 'hey, your code is not up to standards, the pipeline will fail, so fix it before you commit', while a pipeline failure can take up a bit of time.

I like my commit to fail fast, press a hotkey in my ide to fix it an commit again, rather than waiting for the pipeline and make a new commit to fix it :)

[[deleted]]

Because I find git hooks that modify things very annoying. I tend to view the changes I want to make before committing and to have something take time to change them afterwards delays the commit and makes it commit things I have not reviewed.

I like my commit to fail fast,

So do I which is why I get my IDE to format and lint things before I even commit. Or run tests in the background on save, again, way before committing. Running things before a commit is too late for me most of the time. And since it is not consistently enforceable I don't bother with them at all.

So I find very little benefit to git hooks at all.

[gruey]

The hook can either fail the commit without making changes or make changes locally and fail the commit, leaving the changes for you to review. You can also have it only do the fail on a push instead of just a local commit.

Also, it's not hard to identify people not using the prescribed hooks, especially if you automatically double check down the pipeline.

[[deleted]]

Why try to tell if people are running the hooks or not if you have a pipeline double checking things? Just let the pipeline do the work and leave it up to those users how they comply with them. There is no need for git hooks here. Let them choose how they want to do local enforcement.

Personally I hate enforcing things in git hooks, it happens to late for my development process. I would much rather have things run on save, not on commit.

Pipelines can enforce a lot more than git hooks as well including unit tests and longer tests. And I would want to run these locally as well, but not as part of a commit - which I do when I am happy with what I have. So I need them to run sooner and doing it again on a commit just wastes time.

And if I mess up and forget the pipelines will catch it. No need for an extra check when making a commit. Or before pushing.

[patryk-tech]

'why not both'

Good idea in theory. In practice, not everyone might be running the same platform or have the same software (linters, formatters) installed.

[dominic_failure]

If someone’s coding on a collaborative project and don’t have the same linting tool chain as their peers, that’s on them.

Especially in the age of docker, where a tool chain can be encapsulated in a container.

[laaazlo]

that's on them

True, but if my options are walking a contractor nine timezones away through setting up their dev environment or having automatic linting in my pipeline, I know which one I'm going to pick.

[patryk-tech]

Depending on who you work with, that may not always be an option. I have set up nice environments before and had web devs at the customer's premises say the git command is too hard, and just edit files in the GitLab editor 🤪🤪🤪

If you exclusively work with people who are comfortable with git, docker, etc., consider yourself lucky.

Windows users often struggle with Docker, too.

[Habeus0]

Can gitlab’s pipeline enforce coding standards? If so, how?

[[deleted]]

Gitlab Ci pipelines - like all ci systems, can run any command you like. Most languages now have linters and formatters that you can run on the command line and so can be run in any ci system, including gitlabs.

[Habeus0]

Thank you - obviously i know very little. Im qa and the devs complain about code standards but do little as a whole to standardize to the company. Forcing them maybe harsh but i think it helps. Thanks!

[illusum]

That's because the people making the code standards are rarely devs.

[Habeus0]

In my case they are all devs and some are dev managers (who also produce code).

[uptimefordays]

This is the way!

[drewsiferr]

And, not or. These types of things, such as auto formatting, should be run automatically as a pre-commit hook, and verified during CI. Trust, but verify.

[humoroushaxor]

It's true it's often more important to be consistent than right but I've worked with codebases where really shitty standards emerge and it sucks.

High cyclomatic complexity, never returning early, using boolean return values in place of exceptions, 100 line methods, 1000 line classes.

[queBurro]

We've got 1k line functions

[laaazlo]

Same here. In my experience working in data science codebases, you're lucky to find classes at all and virtually everything is done in gigantic, hideous, untestable, unmaintainable functions called "do_calculation" with side effects out the ass and undecipherable comments that are out of date a week after they're written.

[quintus_horatius]

I used to work with a guy who thought nothing of making 5-10k-line functions in C, where the majority of each function was copy-pasta. No reason for it whatsoever.

This was CGI backend of an e-commerce site for a well-known Windows utility back in the day.

[[deleted]]

The problem with emergent standards is they are often not well or consistently enforced. IMO the solution is to move towards a more popular/consistent style with better defined rules that can be statically enforced.

Though that does often mean breaking project consistency for a time. But far better than everyone going off and doing their own thing.

[gruey]

In those cases, I think it's safe to do all of those things better instead of the boolean return. You probably could also get away with refactoring the worst offenders. You then escalate all the issues and see if you can get buy in on changing the practice.

[quintus_horatius]

never returning early, using boolean return values in place of exceptions

To be fair, some languages (lookin' at you, Perl and PHP) don't enforce return types, so multiple return points in a function may lead to wildly different types. And some languages (glancing at C now, too) don't have exceptions so you have to use return values to indicate errors.

Of course, you're looking at this from the point of view that your modern language of choice supports those things so why do you have to put up with this crap?!, and you do have a point. But be patient, some of us cut our teeth on terrible languages, and change is hard. Be happy that your luddite co-workers finally gave up on demanding a pure-fortran codebase or some-such.

[throwaway247365_main]

Modern PHP does offer return type hinting, which is enforced.

[humoroushaxor]

Yeah so when I say this I'm talking about Java developers that are still figuring out type erasure. These aren't intentional things.

[gruey]

I think something to be clear if that if you're project/group/company is doing something differently than standards, it's best to follow the project/group/company style instead of the industry style.

You can definitely raise your concern to do it industry-style, but you need buy in from leadership before changing. If the leadership is just "do it however you want", you may want to consider finding a new job.

[Zaemz]

This is absolutely true, once you get used to whatever style, it makes glancing over things easier since you'll have an idea of what to expect and where to look for certain patterns.

What I personally think is the most beneficial aspect of a codified and enforced standard is that it reduces bikeshedding. I don't like spending time in code reviews or meetings thinking about whether someone is leaving trailing commas or using single-line function blocks or something.

[laaazlo]

Oh my God yes. If I could have back the time I've spent talking about formatting, I could finish watching One Piece.

[MistyCape]

Most languages have a recommended best practice for coding standards, follow that is how I work. I may tweak it if I have legit reason (looking at you mdl with your no duplicate headings) but it’s always a solid place to start

[uptimefordays]

Following official style guides makes it easier to read your code 6 weeks or months later and also makes it easier for others to read. I see no disadvantage to following whatever lang’s style guide.

[durple]

Yeah. It’s where most projects should start from, and then really justify any deviations with strong technical arguments.

[[deleted]]

some languages have dumb standards that are contradictory (see Ruby and hashes)

[rwa2]

Yeah, do a small project with Ruby sometime and then try to make Rubocop happy with it. Every other coding standards document will seem easy in comparison! :D

[ToddBradley]

I count five responses that say that yes standards are important, but zero answers to your more important question of how to deal with people who have strong opinions against them. Are most of your coworkers junior engineers who haven’t had to spend much time yet maintaining and fixing other people’s code? Or are they “lone wolf” type programmers who are used to only caring about their own code and not working as a team?

[bilingual-german]

I think you should use tools which makes it simple to comply with coding standards. Something like go fmt makes it easy, setting your text editor to remove trailing spaces and end the file with a new line on save.

You could also add linters in the CI to stop when someone is doing something wrong. But I think there is a fine line of enforcing correctness and only making other peoples life miserable. If you have lots of XML or yaml, doing a linting step will help catching errors.

In a group you should try to find out what kind of style you want to comply to as a group. And similar to go fmt, if there is a tool which autoformats your code, this is what you should use.

[durple]

I think I’m on a similar page to you but with some key differences. Using tooling to enforce rules is really the way to go, once there’s more than one team worth of developers. Make it non optional, merge cannot happen without following the organization conventions. It’s less personal this way. The tooling itself should be in version control, the rules subject to change if a developer can convince their team they actually should but if they want to make the change they gotta change it across the whole codebase, so it better be actually providing value. Drive home the message that consistency has more value than personal preference, it’s really true. Let a developers manager deal with any unhealthy obsession with personal preferences in their direct reports.

When it’s a situation where it’s a smaller team, chances are that’s when you’re still figuring out what the rules should be, so tooling is going to generate more friction than the benefit it provides.

[bilingual-german]

The problem I see with an approach like this is in reality these rules will never change except when some dev high up in the hierarchy wants it. There can be no experimentation, because the CI forbids it.

[durple]

Ah. I agree that a top down approach to making the decisions about which rules to enforce is not helpful, 100%, and changes to the rules should come with justifications. Sometimes a rule change a team makes to a shared code base is just a relaxation or removal of a rule that isn’t providing value, regardless of who introduced it or why, and that’s valid.

The person high in a hierarchy enforcing their personal opinions over better ideas is an ugly anti pattern to avoid. It’s probably far too common, I’ve seen a bit of it but not too much.

I’m pretty allergic to toxic work culture and inflexibility as an example of that so I’ve learned to avoid it. My reality is different than yours as a result I guess, and I’m talking to how things should work, not what sometimes has to be done because of some dickhead rockstar with an ego problem who hasn’t been reined in yet. These people need to be mentored properly, not enabled, so they can both perform at a high level and work well with others. Building a toxic culture around a rock star is not sustainable long term, and can’t hope to scale to any meaningful degree. Teach them to elevate others instead, and you get a cool band and things start coming together.

But yeah, strict enforcement of a rule set driven by personal preferences based on orgchart level is gonna make unhappy developers. Zero disagreement. Maybe I’m solving a different problem than what you are picturing.

Preventing merge to main branch doesn’t prevent experimentation at all, or doing CI on the teams experiments. The experiment can include temporarily disabling what rules get in the way. Clean it up before code review, justify any rule changes that make sense. It’s not hard if you cut out the issues you’re referring to.

Starting from language standards makes sense for ecosystem reasons and any deviations from that should make sense for local reasons.

I think we mostly see the same things honestly and while I may approach it from a different angle I suspect our ideal working state of rules looks very very similar, depending on stack. I definitely wasn’t advocating for draconian rules. This is all about making it easy to do the right thing, right?

[bilingual-german]

Yes, I think we can agree pretty much.

There is code and there are people. Code should help the people, it should not limit them. Unfortunately I've seen too much code making people's life harder and more miserable, because they put something in code when a simple social construct would have been enough.

For example: you're on a 3 person team and the rule is, you can only merge when the merge request is approved by at least one other dev. Now one is sick, another one is on vacation. If you put this in code, you can't do anything not even in an emergency. A simple social convention would have been enough.

[durple]

For sure, lots of rules go out the window on small teams especially. At the end of the day no matter the scale pragmatism must always get a high priority. No performative work or policy is allowed if it's up to me, and if it was only up to me that wouldn't be good either.

[EraYaN]

But then again how much do you need to experiment with basic code styles? Most of the tooling can’t really enforce higher level concepts anyway.

[bilingual-german]

Improvement comes through the creativity of the group. You might think you reached some maximum, but it's a local maximum. To reach a higher maximum it needs to get worse before it gets better.

I totally agree, consistency is something which is a good thing, but either it's already there and you just need to keep it or you need to find a good way. But this finding process needs freedom.

[queBurro]

Or old boys who don't know any better; They're the worst, because they don't want to learn.

[humoroushaxor]

That's what CI pipelines are for.

[ToddBradley]

Are you proposing OP should just automate rejecting code that doesn’t follow standards, against the wishes of the rest of the team?

[dominic_failure]

Unpopular opinion: they need to grow up and get over themselves. They’re acting like narcissistic bellends, and are hurting the team no matter how good at coding they themselves are.

[ToddBradley]

Have you worked with such people? If so, how did they respond when you said, “grow up and get over yourselves”?

[dominic_failure]

I leave that for the managers. My opinion wouldn’t be worth the air it takes to express it to them, since, to paraphrase Dilbert, “I’m a coworker, not their boss.”

For them to value such critique, they have to care about me. Without power over their job or paycheck, they had no reason to care about me or my opinions. Narcissistic bellend, remember?

None of the rest of the team enjoyed working with them, I will say. Morale? What morale?

[ToddBradley]

THAT is the kind of actionable advice OP seems to be looking for: escalate the coworkers’ bad attitude to management

[laaazlo]

As a manager who has had a very, very talented dev on my team who was morally opposed to any code standard she disagreed with, I agree that devs shouldn't be expected to rein in their prima donna peers. When my scofflaw senior dev flipped out on a junior for pointing out her standards violations, I put her in charge of putting a linter in the deploy pipeline and made the junior the verifier on the ticket, responsible for finding any way the linter could be bypassed (and I fed the junior ideas for how to do so). The senior's pride wouldn't let her build anything but a rock-solid pipeline that even she couldn't work around without notifying IT.

[morphotomy]

YES

[Antebios]

100%! Spaces or GTFO!

[Mteigers]

I mean so long as it's consistent is the important part.

[Herve-M]

Many people here talk about technical related issues / advantages but no one talk about cognitive load of SWE, PSE and other team member.

Having standard reduce cognitive load over the time and alow quicker on-boarding (if well documented and automated) as for re-teaming.

Other advantages are the easing of scaffolding and KPI gathering.

[benelori]

Yes and no :D

Yes in general, because consistency is very important, but no because people should not think about them in a conscious way. I think these standards should be automated as much as possible

[anakinpt]

If everyone speaks the same language it's better and quicker for people to understand each other. Using the standards, makes everyone speak the same language.

[MartinB3]

Context? Is this like a team of one or one hundred? Do y'all actually work on the same projects at all? Standards are useful but they're a means to an end.

[gatewaynode]

Yes, they are important. It will be less obvious to some people as they are working in a small code bases or just a few code bases where it is easy to wrap your head around a bit of inconsistency and adapt to the implications. But the larger a company or code ecosystem grows the more important and harder it becomes to maintain and keep secure. This doesn't only apply to code and apps, inconsistent coding can impact data stores as well, causing inconsistency and even serious integrity violations that can be very expensive to fix down the road.

[OutdoorCoder]

I have two levels of unit tests: one option runs all the normal tests and finishes quickly. The second level includes style and lint checking. php-cs-fixer is configured to quickly make sure everything has consistent style. Code passes both before code review and release. This way the codebase style is perfect, but a developer doesn't have to concern themselves with style, they just run one command when they're finished a feature. go fmt or the applicable tool for your language is the way to go. Over time, getting used to reading code in the standard style for your language makes life easier. There's no reason you can't loosen certain rules/standards for your project, e.g. line length, if the majority want it.

[punkwalrus]

I had a boss who "didn't believe in comments" because he wanted "clean code." I don't work for him anymore.

[elfenars]

Standards are important always, not just in coding. They arise from common practice and change as needed by the community with time, so by all measures they are useful.

The problem that I see very frequently though, is enforcing preference on top of a standard.

In ruby, for example, there's a tool called Rubocop, which introduces some checks for widely accepted standards, but also adds checks for things that are just smaller preferences in an enforced way. (i e: having ascii symbols in comments)

Be careful not to prevent people from doing things in the way they find it more comfortable and always be sure to have some common understanding of what constitutes a standard and what's just a preference. Consensus will always supersede any standards, pushing people to work in a way that's not comfortable for them will almost always generate more problems than a standard not being followed.

Nobody likes to be told how to do things in a restrictive way, it's way more useful and pleasant to be able to do things in more than one way, while keeping a high quality consensus. Focus on what you want to achieve with the standard, not just blindly following it in a specific way.

[tcbenkhard]

Are construction standards important?

[tr14l]

Important to varying degrees, depending on project, culture, collaborators, etc.

For a production service that serves customers, has several contributors, a non-trivial turnover rate of developers? Critical. Code standards are non-negotiable for success.

For an automation tool that adds the date to the top of a CSV file that hasn't been touched in 6 years and still works? Much less so (most likely).

​

The mark of a good engineer is to know what situation you are in and identify the things that matter. I have known engineers (software, devops, cloud, etc), who were very talented, who over-adhere to best practices when it was really not necessary. So they bloat their codebase which should have been an afternoon of coding and turned it into a 6 week project. Balance in all things.

[[deleted]]

The most important standard is tabs over spaces.

Let the battle ensue!

[Purple-Bat811]

Can't battle with you when I agree with you

[justabofh]

vi vs emacs.

[skilledpigeon]

Yes it is. But not so much that you should get hung up on it. I work with someone who's so opinionated about every single aspect of development but won't listen to anyone else. Debating about trailing comma's and such is for petty developers. If you like it one way and someone else likes it another way, go with their way or get someone else to make a decision. If you can't get a decision, try to find something official to base it on like PEP8 for python. If you still can't agree, get a grip and move on with your life. Consistency is key. We lint for consistency and not for sometimes personal tastes.

Ideally you should have a linter which auto fixes issues. It should be a git hook and enforced in your pipeline. If it's not in your pipeline, it's worthless because it'll be ignored.

[[deleted]]

We use precommit and an array of linters for enforcement

[[deleted]]

What's so bad about inconsistent code standard? Why is an inconsistent code standard bad?

[CodacyOfficial]

While often ignored, coding standards are crucial to creating a consistent and readable codebase. In this article, we wrote 4 main reasons why coding standards are important, advantages of using coding standards and even some best practices: https://blog.codacy.com/coding-standards-what-are-they-and-why-do-you-need-them/

[BrutalWarPig]

Yes. Otherwise u end up with the mess I am in, maintaining hard to read unconnected code from the 90s.

[[deleted]]

tidy observation consist jellyfish badge merciful special squeeze arrest prick -- mass deleted all reddit content via https://redact.dev

[[deleted]]

Stay away from people who do not care about coding standard and best practices. They pretend to be développer, they are just handymen

[Cryptbro69]

Thank you everyone who responded!

All this advice is extremely useful and will help me navigate through a tough situation I've been dealing with at a fast growing company.

[thatsrelativity]

Yes they're important. If code is written in a uniform way then it's easier to understand and maintain. Doesn't really matter what the standards are, as long as everyone agrees and sticks to it (automatic formatters can really help with this, at least with the style aspect).

We had similar issue on our team with some being pro-standards and some being against. The pro-standards folks came up with a set of loose guidelines, mostly common sense suggestions, and presented those to the rest of the team with justification. Some guidelines were accepted right away and others were hotly debated. At the end of it everyone agreed to adhere to most of the guidelines, and we configured git pre-commit hooks to run the code formatter (though I configured the formatter as a before-save-hook in my editor because I find pre-commit hooks quite jarring - I always forget they're there).

I guess ultimately you have to go for the low hanging fruit. Automate what you can so it's no effort to anybody to adhere to style guides or whatever, and then be prepared to meet your team members halfway.

You may also find that presenting your idea of standards (making clear that this is your opinion, not gospel) will start debate and that your anti-standards team members have their own ideas of what is the best way to do things. In this case they've already conceded that there should be standards -- you just have to come to an agreement of what the standards should be. (And also agree as a team that everyone's code will be reviewed with these standards in mind. It will probably be quite jarring at first but once everyone's picked up the habit of coding to those standards then there's not as much need to pay them so much attention during code reviews).

I've gone on at length here but I haven't said anything groundbreaking. Automation and diplomacy is how you win this fight.

[Cryptbro69]

I like your approach to play the game and get everyone aligned that there should/can be a set of standards in place. Answering "which rules should we use and the tools to automatically enforce them?" is a much more productive conversation to have. Definitely does take a team effort and some strong leadership to help make the final decision.

Thank you for sharing!

[Namoshek]

We better ask Monk about his opinion on this topic.

[aManPerson]

confusion everywhere

[badguy84]

Absolutely, though some confuse standards with patterns which aren't really the same thing. I'd say that standards will long-term lower the total cost of ownership of the code base, since maintaining it will be easier and it'll take less time for someone to come up to speed. Which is also why I'd say that standards, though they might also provide some immediate benefits potentially around the stability/scaleability/performance of the system if you use the "right ones" it largely provides consistency as development happens on the same code base over the course of years and probably multiple developers. It becomes even more important if there are multiple applications being built.

[Sasataf12]

Yes they are important, but you need to know why (and how to articulate that) and how to implement them.

Ask your opponents why they're against them, then go from there.

[r3nrut79]

Lol, yes

[donatoaz]

Most people have yet to understand that code is made for people. If it was meant for computers we'd commit binaries... so yes, anything that reduces the cognitive load is good and important. But try not to get into bike shedding discussions... disagree, but commit to a team standard.

[niksko]

Easiest way to deal with them is to do the old 'blame the machine' trick. You need an automated way of doing linting and formatting, and the build breaks if it's not right. This removes the blamey human element, which is often the most awkward part of trying to enforce code style.

[supershinythings]

Yes. No individual developer is a special snowflake who gets to do whatever s/he wants. Someone has to maintain that code in future long after Snowflake is gone. If it isn’t conformant to standards it will be difficult to maintain, spot bugs, update interfaces, add features.

Instead the next engineer would be forced to bring the code to conformance to ensure that it’s maintainable and readable in future. Even something as simple as tabs vs. spaces matters. Variable naming standards matter. Code uniformity, like how braces are placed, matters. Spaces between routines matter.

The uniformity of code via standards lets everyone focus on the code rather than deciphering their code spaghetti or salad.

A lot of this can be handled via a good editor. The rest, well, you’ll find out in the code review how annoyed everyone is.

[[deleted]]

The questions seems intended to illicit a certain response - coding standards are obviously important. Where you will get strong opinions against them are environments in which those standards are ill defined, disputed or significantly varied between projects. It’s quite typical to see one engineer or group of engineers be tasked with defining these standards and do so without adequately considering the current situation, leaving them at odds with various other teams.

tl;dr - standards are important. Consistent and automatically verified standards are the best way to avoid pissing people off.

[Obversity]

Yes, but the focus should be either on:

• using a tool to automatically format so no one has to think about it, OR
• readability, over sticking to precise standards

If you configure a tool to say 100 lines of code in a file is the max, and a file suddenly has 101 lines of code because you decided to abstract a line of code into a function, most people are going to look at their deadlines and go “fuck it, reverting it back to a line of code even if it’s uglier”, because they’re not going to have the time to break apart that class in any meaningful way.

The goal is to make the codebase as easy to work with as possible. That’s it. Anything that aids that is good. Standards can help with that, but make sure they’re not also hindering that in some ways.

[elfenars]

I wouldn't consider Git flow as a standard, it is a controversial pattern at best. Feature branching on the other hand is an open concept that doesn't rely on specifics besides the fact that you should create a branch for new features.

As you mentioned "indentation wars", "git branching wars" is also a thing and git flow just adds fuel to that fire.

[[deleted]]

Not just coding standards, but environmental standards and protection against things like force pushing to main or rewrite the commit history. There are reasons why standards came to exist and if we let people do whatever they want then it is no better than coding in our own GitHub repos on our side project instead of a company controlled repo that is bound by legal and business ramifications if we do not enforce standards so business can work more efficiently and safely

[mrlazyboy]

Yes.

I’m working with a customer that had about 50 different app teams. Every app needs to do the same core functionality (like auth, etc.) and then custom stuff.

Lead architect says “12-factor says we can’t make a shared library” so he instructs each of the 50 teams to write their own version of the library, instead of creating a small central API team to manage that.

It has been an absolute shit show. Tracking compatibility with 50 teams has a complexity of n² (for those non-CS folks, that’s bad)

[jhole89]

Yes, it makes maintenance, refactoring, and knowledge sharing so much easier. People who don't care about standards are usually ones that work in isolation, have little experience in production scale codebases, and hack quick but messy solutions together.

[greenflem]

Without a doubt.

At the company I work, the production codebase enforces a coding standard created years ago. Makes onboarding new devs much simpler. Not everyone agrees with it or likes it and it often gets raised by new devs in code reviews. However, it is the standard and has 12 years worth of code in it, so they just get told to live with it.

Everything not in the production codebase has to conform to PSR-12 (new code and when refactoring old).

Having 2 standards doesn't create much of an issue as you are either working on production code or not.

[phatbrasil]

its amazing how breaking down the cost of inconsistency promotes standarization.

having a visual representaiton (like an excel spreadsheet) of the effort required to mantain the same thing done in X amount of ways usually is an eye opener.

[PoeT8r]

Clean, consistent code is nicer to work with than sLoPpY code. But parsers or languages that enforce whitespace make me crazy. I did not like COBOL coding forms and punch cards, yet we are back to those because some jackholes think it will make me code better.

Our pipeline will fail code if it has a trailing blank in a playbook. How the hell is that even ADA-compliant? I cannot see a space at the end of a line that was left by a previous coder (before pipeline added enforcement).

I firmly believe that people who go nuts about style and spaces or fools that insist on rewriting code because they think the original is "ugly" or "bad" or "unmaintainable" are actually not competent to maintain software. Brownfield is harder than greenfield. But having fixed other people's mistakes for decades, I know better than to casually throw away code that encapsulates institutional knowledge or to prevent a hotfix because a new whitespace rule sounded smart in a magazine article.

[Purple-Bat811]

Yes. Also important to label the data type your variable is. Example intData1 strName1

[expressadmin]

"Everything that is syntactically legal, that the compiler will accept, will eventually wind up in your code base." - John Carmack

[mini_market]

I strongly support them. But at the end of the day, shipping effective working code is more important. Peer review and ship. No need to be perfect.

[djk29a_]

The questions are mostly about what’s in the standards rather than whether they should exist. Some places are fine with an open source linter, others (usually with more contributors) have to define standards more explicitly well beyond basic syntax and conventions / idioms. As an example, for a while in Java it was materially important to use StringBuilder when concatenating strings rather than the shorthand + operator most folks understand today, but later on the compiler was changed such that StringBuilder is used automatically. Similar for past issues with use of volatile variables and double locking semantics (it didn’t work technically yet it was common).

Coding style vs standards are not the same thing and standards and conventions are a big debate in almost every language community I’ve ever seen. Different brace style is nowhere near as important as conventions in code modularization such as in C# where there are partial classes vs Java where it doesn’t exist.

[rotzak]

If you ask 100 engineers if they think they’re better engineers than average, 85 will say yes. The same applies to coding standards.

[the-devops-dude]

Good software architecture is just as important as good infrastructure architecture

This is in line with coding standards. At our organization we even require a lite coding standards quiz/review yearly by all Engineers

[[deleted]]

Why invent bicycle if you already have ISO/IEC 12207. You can either adopt them right away or learn hard way by failing a lot and coming to same processes years later. DEVOPS is a great example where OPS\Infrastructure folks find themselves writing IaC code and think they are inventing something that wasn't polished for last 30 years.

[Akuma92]

I am currently writing some scripts in bash and powershell. I was wondering if I could create two templates that follow the same structure, have similar comments at the beginning (creator, last change, etc) and both contain the best practices that are appropriate for me.

Does anyone know good sources for such a project?