progress of the field of software engineering between 2004 and 2016
October 21, 2019 12:22 PM Subscribe
Nowadays, professionally, I am extremely conscious of this sort of style choice or convention, trying hard to ensure it's consistent across the team, organization, or better yet with the rest of the broader community. At the time, though, I was programming basically alone, and idiosyncrasies, like this mistaken naming convention, could persist for years. 3500 words from Li Haoyi, "a software engineer, an early contributor to Scala.js, and the author of many open-source Scala tools such as the Ammonite REPL and FastParse," describing a 300-line version of Asteroids he wrote when he was fourteen.
Or why I always want to throw up when reviewing my old code. I have code from 1983, but scanning it in from printouts would be a chore. That's my excuse and I'm sticking to it. Besides, I know some of my stuff from 93 is still in production and I'm sure gets questioned everyday by the new maintainers.
Some of things he notes, like ALL CAPS and later on switching to camelCase, are a sign of the times. It took me a while and another language to get past under_score separators. Single or Plural collection names? Static and Overloaded code at the top or the bottom of the file? That's just the imperative bleeding into the oo stuff.
Strong preference for functions?
One thing he didn't touch upon in the article, as a Scala programmer, is the strong opinions regarding Scala-as-nicer-Java, Scala-as-multiparadigm, and Scala-as-Functional/Category Theory language, and their influence on practices and conventions of current Scala programmers.
posted by grimjeer at 4:08 PM on October 21, 2019
Some of things he notes, like ALL CAPS and later on switching to camelCase, are a sign of the times. It took me a while and another language to get past under_score separators. Single or Plural collection names? Static and Overloaded code at the top or the bottom of the file? That's just the imperative bleeding into the oo stuff.
Strong preference for functions?
One thing he didn't touch upon in the article, as a Scala programmer, is the strong opinions regarding Scala-as-nicer-Java, Scala-as-multiparadigm, and Scala-as-Functional/Category Theory language, and their influence on practices and conventions of current Scala programmers.
posted by grimjeer at 4:08 PM on October 21, 2019
Ugh, flashbacks to being forced to learn Java and Object-Oriented programming in my 1st year Computer Science courses. The overkill of Java made very little sense to my scripting-oriented brain, the course assignments were contrived, and I’m pretty sure I committed every Java sin in the book because I just couldn’t make myself get it.
Very glad to have found my way towards working with data, with code as a helper rather than a primary product. Equally glad that other people love writing clean code as their primary calling, and make useful libraries that I can import.
posted by mantecol at 8:51 PM on October 21, 2019 [1 favorite]
Very glad to have found my way towards working with data, with code as a helper rather than a primary product. Equally glad that other people love writing clean code as their primary calling, and make useful libraries that I can import.
posted by mantecol at 8:51 PM on October 21, 2019 [1 favorite]
In the companies I worked, I was fortunate in being well enough respected to have a say on programming standards.
I usually tended to throw out the hard and fast rules - except as a fallback option - in favour of allowing people to us their own style - as long as it was acceptable to peer review.
This has the advantages of not stifling individual ideas - which may be better than and therefore become the standard, but also keeping people involved in developing new things.
posted by Burn_IT at 8:21 AM on October 22, 2019 [1 favorite]
I usually tended to throw out the hard and fast rules - except as a fallback option - in favour of allowing people to us their own style - as long as it was acceptable to peer review.
This has the advantages of not stifling individual ideas - which may be better than and therefore become the standard, but also keeping people involved in developing new things.
posted by Burn_IT at 8:21 AM on October 22, 2019 [1 favorite]
... in favour of allowing people to us their own style ... This has the advantages of not stifling individual ideas
I would ... at least mildly push back on this.
Hard and fast rules about how to approach problem solving are bad, but coding style should be enforced automatically at commit time. I don't even care what coding style you pick -- pick anything not insane. Any company spending even a minute in code reviews with people nitpicking over whether braces go on the same line / next line, whether you're indenting the right number of spaces (or god forbid tabs), etc, is wasting time that could be spent on real work. Worse, allowing everyone to have slightly different styles tends to cause code reviews to devolve into nitpicking where everyone's looking at tiny irrelevant details and nobody is actually looking at the overall flow of the code.
The tl;dr for me is, I have no strong opinion on a code style, but I have a nearly unchangeable opinion that there should be a code style, and that it should be enforced by automation always, no exceptions.
posted by tocts at 10:55 AM on October 22, 2019 [1 favorite]
I would ... at least mildly push back on this.
Hard and fast rules about how to approach problem solving are bad, but coding style should be enforced automatically at commit time. I don't even care what coding style you pick -- pick anything not insane. Any company spending even a minute in code reviews with people nitpicking over whether braces go on the same line / next line, whether you're indenting the right number of spaces (or god forbid tabs), etc, is wasting time that could be spent on real work. Worse, allowing everyone to have slightly different styles tends to cause code reviews to devolve into nitpicking where everyone's looking at tiny irrelevant details and nobody is actually looking at the overall flow of the code.
The tl;dr for me is, I have no strong opinion on a code style, but I have a nearly unchangeable opinion that there should be a code style, and that it should be enforced by automation always, no exceptions.
posted by tocts at 10:55 AM on October 22, 2019 [1 favorite]
As professional programming is a social enterprise, adopting and adhering to a uniform coding style is the bare minimum that can be expected. This has the additional advantage of quickly identifying the prima donnas who will subvert the team morale and dynamic.
posted by sjswitzer at 11:17 AM on October 22, 2019
posted by sjswitzer at 11:17 AM on October 22, 2019
In my last programming job, the style rule was: whatever clang-tidy does by default. Saved on a lot of arguments...
posted by pharm at 11:31 AM on October 22, 2019
posted by pharm at 11:31 AM on October 22, 2019
« Older The legal afterlife of Herman Melville's "Bartleby... | Cake village Newer »
This thread has been archived and is closed to new comments
posted by Pyry at 2:06 PM on October 21, 2019