New answers tagged

0

Changing them becomes a major hurdle, and people will adhere safely to the letter of the law rather than engage brains and do the right thing. There will come a day when part of the standard is unhelpful, and makes the code worse. Some people will adhere to the standard, because it's written down and they're safe, and because rules are there to be followed. ...


0

I think many posts here are confusing coding standard with style guide. Making sure that modules developed by different teams have the same compiler options and ABI is a different kind of thing from how many spaces are indented. Things like the proper way to structure #include files and not polluting the global namespace in a header file should be ...


6

To be useful a coding standard must not talk about matters of substance; only matters of style. It should specify only those things that are arbitrary and ambiguous. e.g. Brace placement, indentation depth, spaces vs tabs, naming conventions, etc. Issues of style are local, not global. Each team should adopt their own peculiar style, matched to their ...


1

A very important thing that hasn't been stated clearly enough is that coding standards are like language: they evolve. A written coding standard stands in the way of this, and if it doesn't it's continuously outdated and useless. Not having a nailed down coding standard isn't that bad. If you do peer reviews on check-in, whenever something that isn't ...


0

It depends. To elaborate, the parameters your method accepts should semantically match what you're trying to do. Consider an EmailInviter and these three possible implementations of an invite method: void invite(String emailAddressString) { invite(EmailAddress.parse(emailAddressString)); } void invite(EmailAddress emailAddress) { ... } void invite(User ...


10

Neither is generally better than the other. It's a judgment call you have to make on a case-by-case basis. But in practice, when you're in a position that you can actually make this decision, it's because you get to decide which layer in the overall program architecture should be breaking the object up into primitives, so you should be thinking about the ...


1

Pass around the object, not its constituent state. This supports the object-oriented principles of encapsulation and data hiding. Exposing an object's innards in various method interfaces where it is not necessary violates core OOP principles. What happens if you change the fields in Otherthing? Maybe you change a type, add a field, or remove a field. Now ...


0

Clean Code recommends having as few arguments as possible, which means Object would usually be the better approach and I think it makes some sense. because insertIntoDatabase(new Account(id) , new Otherthing(id, "Value")); is a more readable call than insertIntoDatabase(myAccount.getId(), myOtherthing.getId(), myOtherthing.getValue() );


2

So when you create a function, you're implicitly declaring some contract with code that is calling it. "This function takes this info, and turns it into this other thing (possibly with side effects)". So, should your contract logically be with the objects (however they're implemented), or with the fields that just so happen to be part of these other ...


2

Having the source be the self-documenting coding standard implies two things. People must consult the code base and review it in order to become proficient contributors. This is incredibly important. Reading coding guidelines is a waste of time compared to diving into the code base. It concedes that minor differences are unimportant. It's important to ...


4

Firstly, as far as I know, Uncle Bob is a Java person, this is very important for understanding what he says. When working in a Java or C# team, if the current code has been written by experienced developers, it's easy for me to pick up the coding style and keep up with it. If I am not willing to do so, maybe I was not the right person for the job... If ...


16

Why does Uncle Bob suggest that coding standards shouldn't be written down if you can avoid it? If you're asking reasons behind his opinion then you may have an answer only if he will post an answer here (our opinion is just irrelevant), however... Why shouldn't I write down a Coding Standard? If you're asking if he is right about it: let me be ...


2

Another answer that I don't think has been stated clearly enough, is that it also means that people don't follow the rules blindly. It means that people have to come up with actual justifications for their design decisions and coding conventions, rather than just depending on the the fact that it has been written down to justify it.


66

People overlook the real purpose of a coding standards document, which is to settle disputes. Most of the decisions in the coding standard will have only a very minor effect on readability and productivity. Especially if you adopt the 'normal' style for the language, and language designers are starting to realise that this should be part of the spec (e.g. ...


103

There's another interpretation. I don't believe it is what Uncle Bob meant, but it is worth considering. Don't capture coding standards in a document. Capture it in code, by having an automated process which verifies the standards are being met. Don't rely on people referencing a document, but at the same time, don't rely on people interpreting the code ...


4

Why shouldn't I write down a Coding Standard? There are many reasons for this. Here are some considerations: How much time are people spending "learning" code standards only to have lots of time go into the entire team reviewing, discussing, documenting, revising... etc. code standards. This is like constantly discussing your "Employee Handbook" - how ...


1

A frequently updated and well written code standards document can be very useful, but usually this is not the case. The standards document does not reflect the actual coding standards used by the company since it is very difficult to create a good standards document and even more difficult to keep it up to date. Instead of having a poor and misleading ...


19

Because comments are lies. The coding standard is a great big comment on what the code should be. The code itself is the ultimate source of truth. Truth in this case isn't code behavior, it's the style it's expressed in. If your standards aren't already reflected in your code, you have a lot of work ahead of you. Uncle Bob sees a comment as personal ...


240

There are a few reasons. Nobody reads documentation. Nobody follows the documentation even if they do read it. Nobody updates the documentation even if they do read it and follow it. Writing a list of practices is much less effective than creating a culture. Coding standards are not about what people should do, but are about what they actually do. When ...


0

To be honest, all of the technical responses above seem terribly complicated for the task at hand. As was already written, the code itself is clean and good, so I would opt for the smallest change possible to satisfy the complexity counter. How about the following refactor: public static long parseTimeValue(String sValue) { if (sValue == null) { ...


5

Something meaningful? Nesting lots of meaningless loop variables quickly becomes unreadable. Imagine seeing something like this embedded inside four levels of loops: do_stuff(i,j,k+4, l*i) and trying to understand what it does vs something like: do_stuff(row, col, height + 4, function_value * row) This is a simple example. A lot of this sort of logic ...


4

If there are four or more dimensions, then they represent something more than just cartesian (or other) co-ordinates, so just use a (short) word that signifies what each level actually is.


2

You have several choices which are based on your needs. You can hard code the data. This is done quite often in unit/integration tests and is a valid way of storing this data. It makes it quite difficult to change, especially for a BA/non-developer. You can store it in a file of some sort. The format could be JSON or XML or CSV if you like. If you want ...


3

First of all, I think your code is decent and readable. A couple of things that I see wrong with this implementation here: You're implicitly defining variables using the var in the global space. I would suggest changing these to their actual types. var is reserved for local implicit definitions, and actually this won't compile. See this question for a more ...


6

Another answer already elaborates on the cstdint types and lesser-known variations therein. I'd like to add to that: use domain-specific type names That is, don't declare your parameters and variables to be uint32_t (certainly not long!), but names such as channel_id_type, room_count_type etc. about libraries 3rd party libraries that use long or whatnot ...


16

The only reason I would use long today is when calling or implementing an external interface that uses it. As you say in your post short and int have reasonably stable characteristics across all major desktop/server/mobile platforms today and I see no reason for that to change in the foreseeable future. So I see little reason to avoid them in general. ...


37

No, banning the builtin integer types would be absurd. They should not be abused either, however. If you need an integer that is exactly N bits wide, use std::intN_t (or std::uintN_t if you need an unsigned version). Thinking of int as a 32 bit integer and long long as a 64 bit integer is just wrong. It might happen to be like this on your current platforms ...


199

As you mention in your question, modern software is all about interoperating between platforms and systems on the internet. The C and C++ standards give ranges for integer type sizes, not specific sizes (in contrast with languages like Java and C#). To ensure that your software compiled on different platforms works with the same data the same way and to ...



Top 50 recent answers are included