4 ms·
> It puts an end to useless style arguments. I don't like auto code formatting in my workflow and I don't like "easy"-syntax languages like Go. I see it is of
by jackewiehose 7y ago
> It puts an end to useless style arguments.
I don't like auto code formatting in my workflow and I don't
like "easy"-syntax languages like Go. I see it is of value for
big treadmill-code-machines like google. They want every
codemonkey to be easily replaceable.
But for me code is also art and fun. I align my assignments and
statements and I use different code-formattings according to the
situation.
If I do all right I only write the code once but read it again
and again for years. So I like to spend some time to format my
code nicely, whatever that means :-)
Writing a code formatter is a fun challenge and sometimes its
useful to have a good formatter but please not in my day-to-day
job.
- klodolph 7y agoYou can dislike auto code formatting without disparaging people.
- jackewiehose 7y ago?? You mean the word "codemonkey"? That was meant from the employers point of view. I'm a codemonkey myself...
- klodolph 7y agoI’m not a 1980s network censor chasing after “bad words” here. You painted a nasty picture of a company and its relationship with its employees. You can express yourself without attacks.
- deleted 7y ago[deleted]
- jackewiehose 7y agoI don't see it that way. I think I just painted a picture of reality. I didn't even mean to say this behavior is bad.
- asdfasgasdgasdg 7y ago> They want every codemonkey to be easily replaceable. Code monkeys at Google are very expensive to replace. I'm sure Google would change that if they could, but nobody knows how. Code formatters are definitely not part of any stratagem to accomplish that goal. On the contrary, they want those monkeys spending their time producing value, not arguing over where to put the closing brace. As long as you never work with anyone who disagrees with your style, or whose style you disagree with, an opinionated auto-formatter is not that useful. For the rest of us, it helps a lot. I remember early in my career before Google settled on clang-format, gofmt, etc., how every fourth person had a different opinion on how to indent this or that thing, and how occasionally it came up in code reviews. Or teams had their own team-specific style, so if you needed to fix something in someone else's code you had to break all your habits . . . god, it was horrible. How did we live like that. Now I just run the code fix program before sending for review, and the only points to discuss are naming and software design, not the placement of spaces and newlines. I'm still so thankful for it even half a decade after these concepts became widespread at the company. Fates bless the people who work on code formatters.
- jackewiehose 7y ago> As long as you never work with anyone who disagrees with your style > [...] and the only points to discuss are naming and software design,not the placement of spaces and newlines lol. In my 15 years working with different people in different companies I think I never had a serious argument about code formatting or a serious discussion about placement of spaces and newlines (at most small talk about those issues on coffee & cigarette breaks). Once you are used to jump between different projects and languages you just accept to use the style which is given.
- scotth 7y agooh, I have. Full on per-project style guides, determined in multiple core team meetings at kick-off. And these people were excellent engineers...or at least they were when they weren't focused on minutiae. Even with automatic code formatters, I've gotten into style discussions or been witness to them. At Google! In code review!
- jimsmart 7y ago> They want every codemonkey to be easily replaceable. Most folk/bosses who are risk averse actually want their codemonkeys to be easily replaceable (although admittedly, they might not realise it!). Nobody likes/wants a system with a single-point of failure. If I'm working for a client, and get hit by a bus tomorrow, it is rather reassuring for the client if they know the work they've paid for so far can be fairly easily picked up and completed/maintained by another hire. I deliberately make it part of my strategy to bring a client's attention to this kinda stuff, in an ongoing fashion. It means I can happily spend time on e.g. documentation and/or other technical debt, because my client understands the values of these things. My actions to make myself (more) replaceable lowers my client's risks. (A good client understands this, and might acknowledge and support such efforts with fatter pay checks: someone who helps lower their risks can be a particularly valuable asset) I guess it depends on one's attitude and understanding towards 'being replaceable', and how one pitches that understanding.
- jackewiehose 7y ago> Most folk/bosses who are risk averse actually want their codemonkeys to be easily replaceable Absolutely, everything else wouldn't be very smart. Maybe my comment came off a bit more negative than I intended to. I don't blame google if this mindset is reflected in their tools but I wouldn't like to have to work with that.