What is the freakout?!?!?!?!?!?!?!? Maybe i want to read other peopleās code in a wacky comic-looking silly goofy totally awesome monospaced font!?!?!?!
This is why I spend a good amount of time setting up linters on new repos before even starting to make the application. It saves a ton of time in peer reviews because no one has to think about formatting. Some people may not like the rules chosen but official direction from the boss is āget over itā. There are 0 comments on PRs about formatting which only ever annoys people and is a waste of good dev time.
On my current team, when we were trying to choose a style, my only input was āany style that can be checked/applied with a git commit hook.ā
I get some people prefer reading code in a particular format. Let them configure their editor to apply it, but letās keep the version history in one unavoidably consistent style. Pretty please.
I work on a proprietary language that translates everything to uppercase before compiling. So having a specific case is useless. The standard functions all have wacky cases. Some from the same module may use CamelCase, while itās brother use snake_case.
Ah wellā¦ Guess Iām lucky that it doesnāt bother me.
I use different languages with different style guides and my IDE autoformats everything properly with the click of a button so I donāt think about naming strategies at all.
But also classes? In Java, I normally see camelcase (objects, variables, functions, ā¦) except for class definitions, which are PascalCase.
The package itself often is snakecase though iirc?
When youāre telling a joke to a bunch of computer programmer nerds, you got to tell them what programming language the joke is in, or else it just falls flat.
If people can execute arbitrary code in your app, they can already read your memory, and even if they couldn't they could use java reflection to just turn off the private modifier
Accessibility modifiers are to do with maintainability. If you have internal implementation logic that should be hidden from a consumer you don't want that consumer to have to know about things they shouldn't be changing anyway.
The comic is just about how classnames in java should be in pascal case
I donāt get why every language seems to have its own coding style when youād think theyād be completely interchangeable depending on user/org/project maintainer preference
Iāve found whenever people complain about rust code they can only point out how itās different but not why itās worse and I can usually point to a reason why itās better.
to be fair, I get sometimes itās difficult to pinpoint why something is bad and even ābeing differentā can be a legitimate criticism on its own
People who learnt structural OOP without actually understanding typing system and their benefits really struggle with learning Rist as they try to map classes onto structs and it just doesnāt work.
Traits are not inheritance. Box is not polymorphism. Rust is not C++ with more keywords.
I used to be a PascalCase guy myself, but that changed recently when I had to use React (coming from embbeded C)
I am working with a C embedded framework that uses snake_case, and switching between the two, I realized that it is a lot easier to find information with snake_case for me.
I think Rust actually is actually among the best in this regard for the simple reason that there is consistency given by the compiler. A simple cargo fmt and cargo build will fix or warn you about everything. I can read into Rust codebases so quickly. C++ was always really exhausting because most of the time you were just getting used to the code style.
I felt that. I have a colleague whose coding style is different to mine and whenever they work on code that I originally wrote, I have to resist the temptation to modify things to camelCase.
Format on save is a godsend. Copy paste something with whole indentation? Ctrl-s, itās back to normal. Did some wacky nested anonymous function calls? Ctrl-s, and theyāre laid out nicely.
I honestly almost golf my code nowadays and just let the tooling fix formatting for me. The space bar and enter key are in an ideal world vestigial for the purposes of programming.
Iāll always say that the best code editor is the one that makes you put your idea onto a file the fastest.
So yeah, you shouldnāt worry about style and code lint. You should worry if your code is sound and works. Keep your mind on the logic, not the extras
Last year I had a module for ai stuff. We did things in Python and I am quite into doing things as coding standards say. My mate didnāt really care so much and just went for his style of doing things, also not really worrying about descriptive names etc.
Well, letās say, we werenāt having a good time.
I also realized that I was probably too harsh and tried to go a bit more easy on it later, but many things just felt wrong.
Add black, isort and flake 8 to your repo, you can set it up to be applied on commit.
So folks can modify their local config all they like, and when they push itās to the team standard and when they work locally itās to theirs. Itās the best.
Itās interesting that something this minor gets people so upset. I mean, I get it, but objectively itās weird of us.
I had a debate years ago about test naming. When I was a junior, the lead dev used test methods with an underscore separating different cases. Like testServiceConnector_success(). I thought thatās pretty neat and kept that style. In another project one of the devs almost had a meltdown because I dared introducing underscore scum into āhisā project.
I think it's just that we're possessive/protective of "our" code, even more so if one is passionate about programming. We've put a lot of effort into it, then somebody else comes along and "ruins" our "perfect" (to our eyes) formatting/styling!