I'm developing code for an arduino based board, and I'm using VSCode, as I find it better than the Arduino IDE.
Now, in some parts of the code, I like to group certain statements together, to organise the code better. In C# (using Visual Studio) I would use #region NAME to do this. The C variant of this is #pragma region, however, I find this clutters the code, and isn't quite as clean as I would want it.
Instead I thought of using curly braces {}, to achieve something similar, but to my understanding the compiler uses them to declare scope right? So would using them like this:
char *data;
{
free(data);
}
produce any odd behaviour? From what I've tried the compiler doesn't seem to mind, but maybe I just haven't tried enough cases.
So, I guess what I want to know is: Would using curly braces in this way be detrimental to general coding in C?
The compound statement forms a block scope.
So for example this code snippet
int x;
int y = 10;
x = y;
is not equivalent tp
int x;
{
int y = 10;
}
x = y;
In the last case the compiler will issue an error that the identifier y is not declared.
Also using redundant braces makes a code less readable and confusing.
Arduino is not C only C++.
The best way of organizing the code in C++ is to use classes and structures.
In C# region is used to collapse and expand the code in the editor when outlining and has no effect on the code execution. Arduino IDE does not have any of those fancy editor features.
Compound statement in C or C++ is something completely different than the #region in C#. It creates a new scope that affects the compilation and execution of the code.
Using blocks to group statements and set them off is fine for suitable purposes. One situation I encountered from time to time was when a matrix needed separate processing for its first and last rows, due to border effects. Then the code could look like:
{
int row = 0;
// Code for first row.
}
for (int row = 1; row < N-1; ++row)
{
// Code for middle rows.
}
{
int row = N-1;
// Code for last row.
}
Often the code was largely similar for the three cases, and using blocks each of them made that similarity more visually apparent to the reader. At the same time, having the same level of indentation for each of the cases made the differences easier to see.
Similarly, blocks can organize sections of a function that are semi-repetitive but do not involve loops (and are not involved enough to deserve functions of their own, or that use so many variables that passing them parameters would be a mess).
Blocks are well defined by the C standard and will not produce any “odd behavior.”
Related
My Question for larger coding perspective but I'm trying to understand with simple example. Lets say I have few lines of Code
int main(void) {
int input_1 = 10;
int input_2 = 10;
/* some stuff */
return 0;
}
After reading design principles(I am not sure whether it was common for programming language or not, I hope its generic) I came to know that above code is valid C code but its a dirty code because here I'm not following DRY(Don't repeat yourself) principle as magic number 10 is repeating.
Firstly My doubt is, Does C standard says the same about best practices of coding, I read specs but I didn't get exactly ?
And I modified as below to avoid the phrase Dirty Code
int main(void) { /* I'm not 100 percent sure that this is not dirty code ? */
const int value = 10; /*assigning 10 to const variable*/
int input_1 = value;
int input_2 = value;
/* some stuff */
return 0;
}
Does modified version is the correct or can I do something more better in that ? Finally If these design principles are best suggested than why compilers doesn't produce any warning.
This is more about avoiding magic numbers. Your 10 should have some semantic meaning if you claim it's "the same 10". Then you should do something like
#define FROBNUM 10 // use a name here that explains the meaning of the number
int main(void) {
int input_1 = FROBNUM;
int input_2 = FROBNUM;
/* some stuff */
return 0;
}
Introducing a const is unnecessary, macros solve this problem nicely. DRY is addressed here, the macro definition is the single source of the concrete value.
If there is on the other hand no semantic relationship between the two 10 values, #define two macros instead. This isn't "repeating yourself" if they indeed have a different meaning. Don't misunderstand DRY here.
Side note about your version with const: It has two flaws
The name value isn't semantic at all, so nothing gained, the number is still magic
With this declaration, you introduce a new object of automatic storage duration and type int, which you don't really need. A good compiler would optimize it away, but better not rely on that -- that's why a macro fits better here.
DRY mostly refers to there being one single source of truth. Certain business rules or reusable code patterns should only be expressed once, especially if they may be altered in the future. Examples include code to calculate shipping fees or tax rates, which you want to code exactly once and alter exactly in one place if they change; or the instantiation of a database adapter which you can alter in exactly one place when the database details change.
DRY does not mean that you must reduce every line of code which looks similar to another line of code into one single line.
I have a function that computes the Minimum Spanning Tree of a graph, and I have two different ways to compute the edge weights in the tree.
The edge_weight() function is called inside a few for loops over and over, and which function is used depends on the type of tree, which is specified outside of the main function (by the user).
My problem is that everything inside the for loops besides the edge_weight() function is identical, so I don't want to copy/paste code.
But at the same time I don't want to condition inside the for loops on which edge_weight() function to use, in order to avoid the overhead of a repeated if condition.
So what's the cleanest way to specify which function to use before the for loops start without copy/pasting the same code?
Can I have pointers to functions (does that slow the code down, though?)?
Can I put functions in variables, arrays?
EDIT: Speed is crucial for this application, hence my trying to avoid conditioning inside the for loops.
Here's some pseudo-code:
while(nodes < threshold)
{
for (int i = 0; i < K; i++)
{
if (nodes[i] == something)
{
weight = one_of_two_edge_weight_functions();
I've seen tons of questions about this. Some have answers, some don't, but none seem to work for me. I have this program (somebody else wrote it) that I wish to use. However there are two problems in the constructor:
template<unsigned N>
class Enumeration {
public:
Enumeration(const array<vector<pair<unsigned char, double>>, N>& pDistribution);
}
The problem with this is that I wish to run this class on user defined input. This input decides the value of N. But because of the 1. const requirement on N for arrays, seeing as I need to construct the array that I will use in the constructor and 2. the const requirement N for templates, I am in quite a pickle.
I tried double pointers, using a proxing class or constexpr voids, non seem to work (depending on whether I did it correctly, I'm reletively new in C++).
My last resort is to do something really ugly with a many-cases switch-statement, but I was hoping someone here can help me out. Preferably without using an extension for the compiler.
The class you have shown does not support N being determined at run-time. It is intended for a different purpose, for when N can be determined at compile time.
Trying to allow N be determined at run-time in the above case is almost certainly a bad idea.
Instead, writing a variant of your type such that the outermost container is not an array but rather a vector would be the general approach required to make the size of the outermost container be determined at run time.
This will involve rewriting most of the class.
class Enumeration_Runtime {
public:
Enumeration_Runtime(const std::vector<std::vector<std::pair<unsigned char, double>>>& pDistribution);
};
the const&ness of the parameter might be best turned into a pass-by-value, but I am unsure.
There is no easy route here, because the person who wrote Enumeration<N> wrote it to not allow N to vary at run time.
I have a 3500 lines long C function written by someone else that i need to break it apart without causing any regression. Since it is in C, the main problem i face is maintaining the state of the variables. For example if i break a small part of the code into another function, i will need to pass 10 arguments. Some of them will actually change inside the code of the new function. So effectively i will need to pass a pointer to them. It becomes very messy. Is there is better way of dealing with such refactoring? Any "best practice"?
Unit testing. Extract small portions of the code that depend on 3 variables or less (1 variable best) and test the hell out of it. Replace that code in original function with a call to new function.
Each function should do one thing that is easy to figure out from examining the code.
Instead of passing 10 variables around, put them into a structure and pass that around.
In my opinion, the best thing you can do is to thoroughly study that function, and fully understand its internals. It is more than probable that this function has a lot of anitpatterns inside it, so I'd not try to refactor it: once I knew how it works (which I understand this can suppose a lot of time) I'd throw it away and rewrite the equivalent smaller functions needed, from scratch.
Pack the local variables that are shared between multiple of the sub-functions into a struct and hand the struct around?
Are you stuck with C? I have sometimes converted such functions into a C++ class, where I convert the some (or all) local variables into member variables. Once this step has been done, you can easily break out part of the code into methods that work on the member variables.
In practice this means that a function like:
... do_xxx(...)
{
.. some thousand lines of code...
}
can be converted into:
class xxx_handler
{
public:
xxx_handler(...);
... run(...)
{
part1();
part2();
part3();
return ...;
}
private:
// Member variables goes here.
};
// New replacement function.
... do_xxx(...)
{
xxx_handler handler(...);
return handler.run(...);
}
One thing to start with, as a first step to taking out parts of the function as independent functions, is to move "function global" temp variables to be in tighter scope, something like:
int temp;
temp = 5;
while(temp > 0) {...}
...
temp = open(...);
if (temp < 0) {...}
converted to
{
int temp = 5;
while(temp > 0) {...}
}
...
{
int temp = open(...);
if (temp < 0) {...}
}
After that, it's easier to move each {} block into a separate function, which does one well-defined thing.
But then, most important guideline after having unit tests:
Use version control which supports "cherry-picking" (like git). Commit often, basically whenever it compiles after refactoring something, then commit again (or amend the previous commit if you don't want to have the first commit version around) when it actually works. Learn to use version control's diff tool, and cherry-picking, when you need to roll back after breaking something.
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions' / 'tags' rollover buttons
public void Method {
}
or
public void Method
{
}
Besides personal preference is there any benefit of one style over another? I used to swear by the second method though now use the first style for work and personal projects.
By readability I mean imagine code in those methods - if/else etc...
Google C++ Style Guide suggests
Return type on the same line as function name, parameters on the same line if they fit.
Functions look like this:
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
DoSomething();
...
}
WebKit Coding Style Guidelines suggests
Function definitions: place each brace on its own line.
Right:
int main()
{
...
}
Wrong:
int main() {
...
}
They suggest braces-on-same-line for everything else, though.
GNU Coding Standards suggests
It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.
Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won't start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.
It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this:
static char *
concat (char *s1, char *s2)
{
...
}
or, if you want to use traditional C syntax, format the definition like this:
static char *
concat (s1, s2) /* Name starts in column one here */
char *s1, *s2;
{ /* Open brace in column one here */
...
}
As you can see, everybody has their own opinions. Personally, I prefer the Perl-ish braces-on-same-line-except-for-else, but as long as everybody working on the code can cooperate, it really doesn't matter.
I think it is completely subjective, however, I think it is important to establish code standards for your team and have everyone use the same style. That being said I like the second one (and have made my team use it) because it seems easier to read when it is not your code.
In the old days we used to use the first style (K & R style) because screens were smaller and code was often printed onto this stuff called paper.
These days we have big screen and the second method (ANSI style) makes it easier to see if your brackets match up.
See HERE and HERE for more information.
First one is smaller in terms of number of lines (maybe that is why development -Java- books tend to use that syntax)
Second one is, IMHO easier to read as you always have two aligned brackets.
Anyway both of them are widely used, it's a matter of your personal preferences.
I use the if statement as something to reason on in this highly emotive subject.
if (cond) {
//code
}
by just asking what does the else statement look like? The logical extension of the above is:-
if (cond) {
//code
} else {
//more code
}
Is that readable? I don't think so and its just plain ugly too.
More lines is != less readable. Hence I'd go with your latter option.
Personally I find the second one more readable (aligned curlys).
Its always easiest for a team to go with the defaults, and since Visual Studio and I agree on this, thats my argument. ;-)
Your lines of code count will be considerably less with the first option. :)