• starman@programming.dev
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      1 year ago

      I’d be surprised if there is a serious language that doesn’t come with at least some semi-official style guide.

      Does JavaScript have one?

      Edit: Except google’s style guide

      • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.dbzer0.com
        cake
        link
        fedilink
        arrow-up
        11
        arrow-down
        1
        ·
        1 year ago

        Edit: Except google’s style guide

        This legit made me laugh lol, Google’s style guides for their longer standing languages are always dismissed, especially their one for C++

        • christophski@feddit.uk
          link
          fedilink
          English
          arrow-up
          6
          ·
          1 year ago

          Not sure if they still do it, but Google’s python code is some of the ugliest python I’ve seen and uses 2-space indentation.

          • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.dbzer0.com
            cake
            link
            fedilink
            arrow-up
            6
            ·
            1 year ago

            To summarize the explanations i’ve come across: It’s tailored to Google’s internal teams maintaining tons of legacy C++ code, doesn’t cover exception handling, and generally has outdated advice best suited for the code they developed in that time period. While their style guide is ideal for maintaining consistency with Google’s existing codebase, someone working on a modern C++ project should consider using the language’s more modern features and STL components

            Something I’d want to note though, someone developing in C++ for an embedded platform or even working on hardware drivers would probably have very lean and mean code which doesn’t conform to a particular style guide, especially ones advising against use of “unsafe” operations.

      • Ephera@lemmy.ml
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Google’s, Mozilla’s and Apple’s style guides are pretty much as official as you’re gonna get here.

        The ‘prettier’ formatter is also rather popular and as such its stylistic choices, although that is of course moreso a hammer than a guide.

      • v0rld@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        Is JavaScript a serious language? /s

        Joking aside: One of Brendan Eich’s books probably contains something resembling a style guide.

      • sloppy_diffuser@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        3
        ·
        edit-2
        1 year ago

        Eslint rules and prettier. I use the AirBnB ruleset as a base close to my personal preferences and then customize to my liking.

        I don’t really have to do any manual formatting. I just save to apply the formatting.

        edit: javascript

  • Nachorella@lemmy.sdf.org
    link
    fedilink
    arrow-up
    24
    arrow-down
    1
    ·
    1 year ago

    Rust has a style guide and comes with a linter. But I don’t think you need to follow it if you don’t want.

    • beefsack@lemmy.world
      link
      fedilink
      arrow-up
      16
      ·
      1 year ago

      Rust, like the majority of modern languages, has an official formatter which everyone should be using. Formatters are good enough nowadays that everyone should be using them.

  • Aa!@lemmy.world
    link
    fedilink
    arrow-up
    17
    ·
    1 year ago

    I’m fond of Go, which comes with its own auto formatter. It eliminates all arguments over style and format.

    • TootSweet@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 year ago

      Beat me to it. There’s plenty to rave about in Go, and that’s definitely one of my favorite things.

      Also, it’s refreshing to actually use tab characters and not two spaces or four spaces or whatever.

  • DrDeadCrash@programming.dev
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    If you’re using visual studio (2022 is current) the idiomatic styling will be mostly correct by default (Ctrl k,e will reformat).

    • brian@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      I’ve found it to be less strict than I’d prefer. Things like whether parameters are aligned or indented, whether or not the first one is on its own line, what statements are indented in fluent calls that have blocks, etc.

      A lot of other formatters (prettier, anything for python, etc) force something consistent in those cases, whereas it seems like the dotnet formatter prefers to leave things as they were.

      I’d love for it to be more opinionated and heavy handed if anyone has suggestions

  • Kogasa@programming.dev
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    For practical advice, I recommend starting a project with dotnet new editorconfig which covers many of the .NET coding conventions. If you want more strict standards you can use StyleCop, but you will need to configure it a bit to be consistent with the .NET conventions.

  • NuXCOM_90Percent
    link
    fedilink
    arrow-up
    7
    arrow-down
    3
    ·
    1 year ago

    Most languages with “official” formatting guidelines are due to limitations of the compiler/interpreter. Mixing whitespace in Python (or older Fortran) is a great way to error out massively.

    For the more modern compiled languages, there is no need. But there still tend to be popular formats from companies like Google

    • Kogasa@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      You say this, but C# does have official code style conventions. It’s not about the compiler at all but about ensuring a relatively homogeneous coding style across the ecosystem, so a .NET dev can work on different projects without needing to refamiliarize.

      • NuXCOM_90Percent
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        If indentation and newline policies prevent developers from migrating from one project to another then either your developer suck or your language does.

        That said, C# is somewhat special in that it is both a language and a corporate flag by Microsoft. Similar to how Google pushes to have their style guides made public so that other projects will adopt them. Which has less to do about making it so that one developer can bounce between projects (because they should be able to anyway) but to instead push Google as the goal everyone aspires to and emulates.

        • stevecrox@kbin.social
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 year ago

          This is about thew new starter cost.

          When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc… Often this impacts other members of the team lowering the entire teams productivity.

          When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.

          So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.

          Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.

          Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).

          • NuXCOM_90Percent
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            Tools and frameworks do indeed take time to come up to speed on. That is onboarding and training

            Code formatting should not. If it is taking new developers any meaningful degree of time to adapt to a new style then, again, either your developer or your style sucks. The time it takes to ping HR because they never sent you a document is a much bigger delay than anything else.

            And, the very nature of coming up to speed on a code base ensures you figure out any quirks. Because you aren’t making a 10 thousand line pull request on your first day. You are doing something small. So you can get your editor set up to automate most of that and the rest you figure out while going through code review/linting/pre-commit.

            So yes, different coding styles will result in minor fluctuations on your “productivity tracking” software. So does having a chair where the reclining lock is in a different position or remembering where the coffee machine is. And if you are at the point where you are optimizing having your developers learn the preferred structure for an if block? You have already won and have the most optimized organization on the planet.

            But the reality is that this is the kind of thing that bean counters who use productivity trackers get off on. It allows managers to quantify their employees without ever having to understand what they are doing. And it similarly provides a quantifiable way to say “I improved efficiency by 4% relative to some baseline I cherry picked from the day after a long weekend. Money please!”. Often at the cost of annoying their staff and decreasing the time before people update their linkedins.


            Fun story/group therapy time! Couple years back I was on a project where the lead was a REAL moron. Got the job because he was married to the head of a different department and threatened to leave if he didn’t have opportunities for career advancement, etc. Anywho, he insisted we all needed to switch to a “more efficient” coding style (I don’t think it was the google style guide, but one of the popular ones). Took a whole day off of development so we could sit through presentations and do exercises on the benefits of this style while also, obviously, not having time to just set up the pre-commit hooks to automate the migration.

            But I was actually in the final days before taking leadership on a different project (which made handing off responsibilities a real pain in the ass but…). And he presented on how amazing the improvements were during one of the project leads meetings. I want to say he measured something like a 30% improvement in SLOC per day which set my BS alarm off massively. Fortunately, as a lead, I now had access to the tools used to collect those metrics. He chose the day where nobody was allowed to code for about 6 hours straight because we were learning about the new system as his baseline. And still only had a 30% gain…

        • Kogasa@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          There’s a lot more than indentation and newline policies. The default editorconfig is a few hundred lines. But there’s also no reason not to standardize indentation and newline policies.

          • NuXCOM_90Percent
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Standardizing within a project or even a company is important.

            Standardizing across an industry or language is not

            • Kogasa@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              Feel free to point out a disadvantage. As a .NET dev I appreciate the semblance of consistency. Different codebases differ enough already, it’s just easier on the eyes when everyone is using the same basic conventions.

  • navigatron@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    JavaScript / TypeScript are famously free-form, but a number of styles (and style-enforcing tools) have emerged.

    “Prettier” is the most recent. It actually parses your code into an AST and then re-prints it according to its style.

    “ESLint” is the most widespread; it is more of a framework into which rules can be plugged.

    I use “XO”, which is essentially a custom eslint ruleset with a few other nice things tacked on.

    The best part of eslint/xo is the “—fix” command, which can auto-fix most mistakes.

  • amio@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Sort of. Python is a lot more ceremonious about its PEPs or whatever, but there are official naming guidelines for .NET in general at least. The rest of it falls more under the general “this and that is considered ‘good’ code, this and that is not”. You could prefer ancient-style C# or heavily functional C#, there’s the SOLID stuff that applies both generally and specifically to OOP, etc

  • nephs@lemmygrad.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Javascript has airbnb style guide, enforceable through eslint. There’s also react related eslint extensions to give you a lot of best practices to follow.

    There’s also prettier, which is just about formatting.

  • TehPers@beehaw.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Someone else already mentioned Rust, but to add to it, rustup installs rustfmt (opinionated formatter) and clippy (linter) by default, but you can choose not to run them or even install them. rustfmt has a few configuration options, but is for the most part strict in how it formats code.

    PEP8 is nice since it sets some common rules across Python projects, but I’m not a fan of some of the decisions they made. The biggest one for me was discouraging defining variables/attributes/etc that use the same name as built-ins. That means no variable named input, no attr on your data model named id, etc. Still, since the language doesn’t strictly enforce this, you can easily adjust these rules to meet your project’s needs.

    I believe go requires you to run the bundled formatter to even compile the code, but I could be misremembering.