191–200 of 360 posts
Is anyone else uncomfortable with Github/MS owning more and more of your tool chain? Maybe my lock-in radar is faulty, but the more this happens, the more scared I get.
Earlier quoted context omitted.
The 88 character limit is just a best effort thing anyway. I find the double-quote coercion more disruptive.
I started programming in the 80s, so I'm used to double-quoting anyway. Apostrophes occur so often in English that it makes it easier to type strings like "I'm a dog". With single quoting you have to go 'I\'m a dog'. If I hit double quotes in a string, I just triple-quote. """He said "hah" sarcastically""". I know Guido (van Rossum) prefers single quotes -- I'm not sure why exactly -- so it's become a default Python…
Might be ease of typing? Eg: `foo = 'bar'` doesn't require any shift chords, whereas `foo = "bar"` requires two. Though then I'd expect similar preference for kebab-case in identifies, for similar reason.
Am I the only one that dislikes linting? Btw, you don't have to respond with the talking points I've heard all my life on why it's supposedly great, I've obviously heard them and think they're bogus. I just find it strange that I'm the only one.
What do you dislike about bugs being highlighted as you type, rather than first having to run your code?
many things "highlighted as you type" aren't "bugs".
let greeting = "Hello " + user.name;
but... I might be making a change to it a few minutes later... but I've got some damn visual shit flashing in my eyes that "USE A CONST"
concat strings? PREFER TEMPLATE!!!
OK, ESlint, have it your way, please auto-correct that...
`Hello ${ user.name}`;
And... this is just one set of 'best practices' to learn - change per language/framework/team multiple times (sometimes in the same week) and it's... difficult.
Yes, I'm an old-fogey. I have close to 30 years of muscle memory of using string concat and double quotes. "auto-fixing as I type" brings a huge interruption of flow, and THESE ARE NOT BUGS. They are style choices someone else is imposing on me. It doesn't make the code less buggy. It doesn't make the client any happier. If someone else coming in to the code is genuinely confused, confounded or severely impeded by
let greeting = "Hello " + user.name;
Goodness help folks when new management comes in and demands a new 'better' style.
Earlier quoted context omitted.
So are you saying sometimes you want to initialise a variable without ever doing anything with it afterwards? That that's not the result of a typo down in your code in the vast majority of cases? I mean, I'll be the first to agree that blocking your development in the heat of it over some stylistic issue like quote styles is counter-productive, but if those rules are turned off and the rest help you catch actual bugs…
It hasn't been my experience. I have had to deal with linters probably about 15,000 or so hours of my work life (luckily that's only about a third). It's been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the linter. It's not like I'm some grumpy malcontent that hasn't given it a go. If you want to use it go ahead, I just thought I'd be standing in a larger crowd
I've got my linters set up pretty loosely, but the things that are enabled have definitely helped me detect bugs earlier and quicker, and I really don't see how anyone could be against that.
There seems to be a universal law of software systems that if small, self-contained subsystems exist - someone will glom them all together into an Uber-system, and vice versa. It’s inescapable.
Yes, this is a bit different, but, you know, having a super-linter around would be kinda handy. It gets old installing and configuring these things sometimes.
Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…
One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away…
Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"
Earlier quoted context omitted.
So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.
I would be a bit surprised if this is true, because it implies that when you're writing code that will be formatted you do not think of the reader's experience. This could be the case if you have extreme confidence in the formatter, but I have def seen some very funky black outputs. It seems like when writing people will likely do so with a model of how black will yield the final code in mind. (Eg "if I add more char…
Earlier quoted context omitted.
Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…
Why don’t we just check ASTs in to git instead of text files ?
Earlier quoted context omitted.
I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code…
I feel like this is a team preference problem and not a formatter problem. The formatter will only do what you tell it, spaces or tabs. Looking at this another way, formatters are designed to "frustrate" devs into working only 1 way. If you think it's more helpful to have a codebase with mixed spaces/tabs with commits that express each developer's unique flair, then a formatter is not for your team.