281–290 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.
I am starting to feel this way about just git.
Earlier quoted context omitted.
I have thought about this a bit in the past, and I think the answer is that the AST for a given blob of text can be different depending on which version of the language you interpret it with. consider 'print "foo"' in python 2.7: Python 2.7.15 (default, Feb 14 2019, 16:26:56) [GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.…
I suspect you're probably right, but that example isn't the greatest because Python 3 isn't source compatible with Python 2. The source code text itself isn't even backwards compatible in that case.
I tried to make an example with `with`, because that was introduced between 2.4 and 2.5 IIRC, and 2.4 and 2.5 aren't nearly as far apart as 2.* and 3.*, but I didn't find an easy way to install a 2.4 python (it didn't compile in pyenv on my mac, and I looked at a couple docker images before giving up).
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.
this is a solved problem, pin your packages.
But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.
Earlier quoted context omitted.
I have thought about this a bit in the past, and I think the answer is that the AST for a given blob of text can be different depending on which version of the language you interpret it with. consider 'print "foo"' in python 2.7: Python 2.7.15 (default, Feb 14 2019, 16:26:56) [GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.…
I suspect you're probably right, but that example isn't the greatest because Python 3 isn't source compatible with Python 2. The source code text itself isn't even backwards compatible in that case.
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…
Earlier quoted context omitted.
You're not the only one. As a freelance/contractor, my environments change, often daily/weekly. I routinely switch between Java, PHP, Vue, React and some other tools. Doesn't matter WHAT I do, I end up having some stupid red squiggles telling me I can't use "double-quotes" or that I can't use 'single-quotes', depending on context. Multiple languages and 'community standards' conflict with each other, and I'm always c…
> It does mean that some people who place a high value on standards and listing and visual style are placated. This times a million. It doesn't help that the advocates of linting are so dogmatic about the whole idea (as demonstrated so colorfully in this thread and this sub-thread in particular). I mean, I understand why. Linting is an all or nothing type of thing. But I'm still going to remember the lint-advocate as…
Hyper-concern of linting is in my top 10 red flags of an engineer that is likely unable to prioritize without significant and continuous direction from a PM. It definitely does not mean that are not a skilled developer. Often it does indicate they are quite good. But it also indicates they can not be left alone too long without supervision.
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…
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…
Earlier quoted context omitted.
> It decides to undo your work What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.
Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.
If the rule never works for you, turn that one off.
If the rule is what you want 99% of the time but it made this one line look dumb, mark that one block #ignore and let the team decide in CR if that was the right call.