Yes, I personally like this style.
Its not a lack of thinking or laziness. Its just easier to read.
291 karma · joined July 30, 2018
Its not a lack of thinking or laziness. Its just easier to read.
2. My experience says that is too static way of thinking. Maybe I work in too fast paced place, but usually we learn that previous written software is not good today and we need to rewrite the code to make it better. Rarely have I seen that interfaces stays the same forever.
3. Whats the difference here? Squashing on a development branch vs on merge? Btw I do commits daily with good messages, but I am just wondering what I get from this if I loose it later anyway.
> Do you mean linters that enforce maximum line widths? That seems increasingly rare these days.
Yes, that is what I mean, and I see it more and more because some think passing a linter test will make your code good.
Some things to consider imo:
1. Using x as variable name can sometimes increase readability. For generic functions that are close to mathematics it is not a sin to use such variable names. Though way to often I get pointed out to rename it to something more descriptive. Longer variable names can also leads to worse readability since a linter will now make 1-liner split into a 4-liner.
2. Tests: "With increasing complexity your codebase will become much harder to maintain and control — tests will do it for you." Good intentions here but be careful. Tests can cause people not wanting to refactor/fix because now they have to fix the structure of the tests. Refactor means more than changing the implementation of functions.
3. "Commit daily,... . Give meaningful commit messages." I am starting to see a trend where PRs get squashed into one commit. Thus making such advice not very useful.
Some developers even do that with themes. Yeah, I am not going to DL a theme file only to find out I don't like.