New answers tagged coding-style
1
In reality, lots of times your code is just fast enough, so you do nothing.
If it’s not fast enough, lots of times you don’t need to optimise, you just have to figure out what you did that was completely stupid and killed performance, and stop doing it. That has been my experience in recent years, that when something was too slow, it was because of someone ...
4
Unless there is a good reason not to (meaning your string needs the terminator), I would prefer changing the signature:
void foo(std::string_view path)
It potentially increases efficiency for the caller and the callee.
And doing
if (path.empty())
path = "some default";
is thereafter efficient and the obvious thing to do.
Go for a good interface ...
1
Yes, it is a bit weird to change the signature of a function because of the implementation. I would prefer option A because of the mentioned reason and because it is more restrictive.
Assuming the function parameter is used to open a file at a given path, it makes a lot of sense to declare it const. But I also see no reason to use pass-by-reference using ...
0
Make it work, then make it beautiful, then if you
really, really have to, make it fast. 90 percent of the time, if you
make it beautiful, it will already be fast. So really, just make it
beautiful!
by Joe Armstrong
1
I see lots of good answers, but not one currently answering your literal question
So I'd like to know if they have a founded reason to exist.
As I remember correctly, each of these techniques had their justification around 20 to 30 years ago on slow hardware, especially for some not-so-sophisticated compilers or interpreters, in cases where even micro-...
1
In the case of an SQL engine such as MySQL, the best option is to let the DB engine and its optimizer do the job: send the complex query and get the results.
There are several reasons for that:
SQL engines have in general an optimizer that is able to chose the best access strategy, taking into account dynamically the size of the tables, the existence ...
4
Three quotes to sumarize good practices regarding optimizations:
Premature optimization is the root of all evil Donald Knuth
Don't diddle code, find better algorithms Kernighan&Plauger
Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it....
2
Not specific to C++ but one of the most common misconceptions I see is the idea that things will be faster if you pull all your data together before moving to the next step of your algorithm. This manifests itself in a number of ways. For example:
Building gigantic data messages
Loading large data structures into memory
Running process A for every item in ...
17
Performance optimization doesn't lend itself to these kinds of generalized rules, and I'm not sure that the rules you proposed were ever good ways to optimize.
Here's a better plan:
Set specific performance requirements. (i.e. define "good enough.")
Start with well-written code that takes advantage of routine performance optimizations such as sensible ...
5
"Big function (several thousand lines) to avoid function call overhead"
In my experience exactly the opposite. Compilers tend to have problems creating good code for huge functions. I've had examples where execution time was really important to me, and I got considerable measurable speedup by extracting small loops into separate functions - code generated ...
0
The code will work regardless of whether you capitalise constants. These so-called "constants" are just variables that won't change during the code execution.
My personal opinion is that if they are capitalised it is easier to remember they are supposed to be constants.
import operator
OPERATIONS = {"+": operator.add, "-": operator.sub}
def check_answer(...
3
I think it's important to understand proper OOP from a traditional sense, and what is necessary for data binding, etc. Java introduced the JavaBean (POJO with only getters and setters) to bind to the user interface. Most people are not building user interfaces in Java these days, but they still have their place. First, let's distinguish between OOP and ...
0
In addition to suggestions here, I strongly recommend you use screen sharing to do some pair programming sessions so that developers can work together. NOT all day every day, just a few hours a week of working as a pair and mixing up who pairs with whom will have tremendous payoff in terms of normalizing practices and sharing tips with each other.
0
Robert's answer is great, but there's a bit more that can be said about your technical designs' impact on teamwork.
unit tests. (Yup, we're one of the people not doing those yet...)
Unit tests aren't... necessary, if you aren't using OO. If you are using OO, tests help to warn you when your code breaks. But the tests are subject to the same rules as any ...
2
If the team culture have been working well with each developer having their own domain and styles, and people are happy with the situation, then don't try to change that. If this isolation isn't a problem, don't make it a problem.
Make it so that following local standards is the general rule. The leader for each domain should decide what the standards for ...
1
It's not clear why the coding style matters to you. Is it because it provoked disagreement thus wasting time and creating friction, or is it because it's causing problems in the running of the software, or is it because it makes it hard to write/maintain the software?
So, the first thing to do is work out the why or the what and the how will likely elude ...
4
I think you are trying to solve the wrong problem. As I understand, your problem is that every developer is working in his silo and other developers only jump in if problems are serious. Of course, having a common (deep coding) style can help in this case but I think the better option is to break the silos first. As long as you are working in isolation, ...
3
Given that there's so few of us and there's just so much work to be done, for most part each developer handles a separate part of the system and doesn't share their work much with other developers. Each has their "domain" so to say.
This is more of a problem than it appears. Having only one developer on a project encourages this sort of overprotectiveness, ...
6
Your stated goal for the meeting was to discuss Unit Tests to improve code quality among a group of experienced devs. You then found yourself arguing about:
How to name things. What folders and namespaces to place them in. Do I
split this code into 3 classes or just one? 5 tiny files or 1 gigantic
one? Abstract it away with interfaces and factories, ...
4
Since this is not just about the superficial style, but about the way people write, I strongly suspect that if you force a way of writhing and thinking on everyone, in the form of a "standard", you will stifle the creativity of your team members, and that could kill your team/company. What you need to do is work on turning those shouting matches into ...
13
The first step (and it sounds like you're already well on the way to this) is to get agreement from all of the developers that there is a problem, and it needs to be fixed. They all need to understand that they may need to change some of their habits for the greater good. It's a near-certainty that everyone will have to change at least one thing about the ...
5
Dont't have a coding standard other than what is customary for the platform. And assume that your developers are all adults.
Two rules: If you edit a file, you adapt to its coding style. And new code is written in the style of the developer who writes it.
And be tolerant. No need for shouting. Who shouts is wrong.
Top 50 recent answers are included
