A colleague spent a few hours tracking down a python bug caused by a bad merge that messed up the indent without it outright causing the code to crash, just produce wrong output. That's IMO too expensive a bug type to permit just to save a few keystrokes. But YMMV as they say.
Re: the bad merge, that can happen the other way to: this was the cause of Apple's infamous goto fail bug. I think block structured languages should do what go and some others do: braces on conditionals and loops are mandatory, parens are optional.
That’s a 1000x advantage in my book. Not mention exceptions are often avoided with a professional editor with whitespace highlighting and indentation guides.
You're not even trying to have a reasonable discussion about this, are you.
At least this guy has a datapoint. You just have a hunch that you can write code faster if it's formatted slightly differently. I don't think it's true -- I don't think typing semicolons and curly braces slows down my coding enough to warrant omitting them. Most of my time coding is spent thinking and reading, probably less than 15% of my time is spent typing. So if I only type semicolons and commas 5% of that time, that means I'm saving 0.75% of my time by not typing them, which is about 14 hours a year if I work 40 hour weeks.
I've definitely debugged a yaml error or two due solely to formatting in the past year, which probably cost me at least 4 hours of productivity. If my entire codebase was formatted solely by indents and returns, I imagine that number would balloon significantly, which is why I opt to use semicolons and other formatting characters.
Also, they're not "reading impediments," at least not universally. Being able to use my code-editor to jump to the end of a code block (by matching a { or }) has been immensely useful in my experience.
If you need 4 hours to fix a yaml file, then what can I say? Perhaps you need better tools, or reduce tech debt.
Not to my knowledge, and I have a great interest in UIs and usability, so a link would be very interesting. It would also help resolve a lot of whitespace vs. brackets debates if you can find it, thanks.
> But there are more uncharitable interpretations
That was nasty.
You're unlikely to find many peer-reviewed studies on this, the way you won't find many on proving other things learned centuries past.
- http://impact-information.com/impactinfo/readability02.pdf (about prose but mentions bullet points with space)
- https://www.researchgate.net/publication/320407173_A_COMPARI...
- https://alistapart.com/article/whitespace/
- https://softwareengineering.stackexchange.com/questions/2985...
- https://ieeexplore.ieee.org/document/8091188
- https://dl.acm.org/doi/10.1109/ASE.2019.00047
A quicker method however: Do you find regular expressions more readable than string methods? If so, you're highly unique. If not, you already agree.
That paper's worth nothing. It's literally schoolwork.
and one I looked at is https://alistapart.com/article/whitespace/ Whitespace is used there as a feature of graphics layout mainly (though text too, as margins, space between lines etc). From it
“Whitespace,” or “negative space” is the space between elements in a composition
As for the question about regexps, they aren't punctuation that punctuates anything else, they're a mini, dense string language. They reveal nothing about python spaces vs braces, and nothing about punctuation in an informal or formal language.
To answer your question about regexps, which is clearer depends on what's required. A common emacs regex is to remove left-spaces from data:
^[ \t]+ -> (empty string here)
To swap 2 fields separated by a space (assuming the 2 fields don't contain spaces, common in data scrubbing):
\(.\) \(.\) -> \2 \1
In these cases regexps are cleaner than methods, but that I find it so neither supports nor denies agreement with you.
This is silly. Good night.
Yes, recognizing a bug, investigating it, sourcing it to a yaml file, finding the offending line, fixing it and testing it, and getting the fix merged up probably took me a minimum of 2 hours, and I had to do it at least twice.
You just handwave away every argument that is brought against you, without actually thinking about what you're saying or if it's even true. You're the worst type of engineer.