Software engineering topics I changed my mind on
chriskiehl.com
Software engineering topics I changed my mind on
1–10 of 704 posts
Re: Software engineering topics I changed my mind on
#2I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
Re: Software engineering topics I changed my mind on
#3Are the things under "Things I've changed my mind on" things you believe now, or have stopped believing?
(Can't tell which way the change of mind is.)
Re: Software engineering topics I changed my mind on
#4Some explanation as to why the opinion changed for or against would be nice.
Re: Software engineering topics I changed my mind on
#5I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.
Re: Software engineering topics I changed my mind on
#6> DRY is about avoiding a specific problem, not an end goal unto itself.
To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. The former leads to elegant abstraction, while the latter just leads to functions with signatures like my_function(data, BITFIELD, opt1=false, opt2=true, opt3=false, BITFIELD);
Re: Software engineering topics I changed my mind on
#7I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.
Yes, we use golangci-lint for our few Go projects, which works well. However, most of our projects are in Java, and the mistake of our team was to never have our Checkstyle break the build. So, the result is many Java repos with a variety of coding styles.
Re: Software engineering topics I changed my mind on
#8I wonder why he changed his mind to these. They don’t seem that controversial.
Re: Software engineering topics I changed my mind on
#9I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
I wouldn't worry. In my (long) experience there are many of you.
Re: Software engineering topics I changed my mind on
#10I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.
Then you get to have many meetings about which litter and lint rules to use.