391–400 of 552 posts
Finding flow while coding is a juggling act to keep things in the Goldilocks zone: not too hard, not too easy.
This is tricky on an individual level and even trickier for a team / project.
Coding is communicating how to solve a problem to yourself, your team, stakeholders and lastly the computer.
The Empathic Programmer?
Earlier quoted context omitted.
Which is why I consider DRY (Don't Repeat Yourself) to be an anti-rule until an application is fairly well understood and multiple versions exist. DO repeat yourself, and do not create some smart version of what you think the problem is before you're attempting the 3rd version. Version 1 is how you figure out the problem space, version 2 is how you figure out your solution as a maintainable dynamic thing within a cha…
Closely related to the Rule of Three - ok to duplicate once, but if it is needed a third time, consider refactoring: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... I think it's a pretty good compromise. I have tried in the past not to duplicate code at all, and it often ends up more pain than gain. Allow copy/paste if code is needed in two different places, but refactor if needed in three or more, is…
Earlier quoted context omitted.
The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…
Software developers don’t arrive fully formed. Rob Pike benefitted from reading a book or two.
In order to get a sense of what code is harder to understand you will do better to read code and have others read your code. A good takeaway is to keep this in mind (amongst many other factors) and to understand code needs to be maintained, extended, adapted etc.
The ideas are still useful. The danger is blindly applying rules. As long as the reader knows not to apply any of the suggestions if they don't understand why and have relevant experience ;)
Earlier quoted context omitted.
The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…
The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…
https://github.com/fzipp/gocyclo
> * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does.
https://github.com/mgechev/revive
> Now is this going to buy you good architecture for free, of course not.
It's not architecture to tell people to comment on their functions.
Also FTR, people confuse cyclomatic complexity for automagically making code confusing to the weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.
Earlier quoted context omitted.
Mort is the pragmatist, Einstein is the perfectionist, and Elvis is... let's be honest, Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate? I see the ideal as a combination of Mort and Einstein that want to keep it simple enough that it can be delivered (less abstraction, distilled requirements) while ensuring the code is sufficiently correct (not necessarily "elegant" mind…
> Elvis is basically cancer to a project. I guess maybe a small dose of Elvis can help motivate? Sometimes teams are quite stuck in their ways because they don’t have the capacity or desire to explore anything new. For example, an Elvis would probably introduce containers which would eliminate a class of dependency and runtime environment related issues, alongside allowing CI to become easier and simpler, even though…
Elvis and Einstein joined powers to create 14 new javascript package managers over a handful of years while Mort tore his hair out.
Earlier quoted context omitted.
If you notice that two parts of the code look similar, but have a good reason not to merge or refactor, that deserves a signpost comment. If you're copying and pasting something, there probably isn't a good reason for that. (The best common reason I can think of is "the language / framework demands so much boilerplate to reuse this little bit of code that it's a net loss" — which is still a bad feeling.) If you rewri…
I don't think it's as cut and dry as that. In my team we require 100% test coverage. Every file requires an accompanying test file, and every test file is set up with a bunch of mocks. Sure, we could take the Foo, Bar, and Baz tables that share 80-90% of common logic and have them inherit from a common, shared, abstract component. We've discussed it in the past. Maybe it's the better solution, maybe not. But it would…
What made your team decide on that rule? Could your team decide to drop it since it hinders improving the design of your code?
Earlier quoted context omitted.
The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…
> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. https://github.com/fzipp/gocyclo > * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very careful…
Not weird at all:
https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...
Earlier quoted context omitted.
The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…
The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…
Not everything is complicated, most functions don't need comments, why require it? Just fix complexity when it arises. Don't mandate that you can't make any complexity.
Earlier quoted context omitted.
The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arguments. I like the article but the people who need it won't understand it and the people who don't need it already know this. As we say, it's not a technical problem, it's always a people and culture problem. Architecture just follows people and culture. If you…
> Every rule can be used to argue anything. Unless it's a rule prohibiting complexity by removing technologies. Here's a set of rules I have in my head. 1. No multithreading. (See Mozilla's "You must be this high" sign) 2. No visitor pattern. (See grug oriented development) 3. No observer pattern. (See django when signals need to run in a particular order) 4. No custom DSL's. (I need to add a new operator, damnit, an…
Earlier quoted context omitted.
The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility a…
> Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. https://github.com/fzipp/gocyclo > * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very careful…
https://eslint.org/docs/latest/rules/no-else-return#rule-det...
But never using it is crazy.