Return to Answer

Added point about performance hit

edited Feb 2, 2013 at 14:20

Comments

Because your question is marked clean-code and I see that you have commented your declaration of the variable command with the comment command, let me make a note about comments. There are good comments, and bad comments; in my experience, a very high numbers of comments written by many developers are bad. For a thoughtful exposition of comments, see Bob Martin's chapter on them in Clean Code (an invaluable book). In short, if you are going to insert a comment, make sure it actually adds something. Then, make sure you can't add that information into the code itself, by renaming variables, etc. Then, if you can't, carefully craft your comment.

Functions

Because you are asking about the general cleanliness of your code, let me advice that you use smaller functions. There are many benefits to small functions, which I will not get into here; many of the best software books discuss this, including Martin's book, mentioned above.

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

In Unix, C and C-based languages, you have three streams attached to your process by default: standard in, standard out, and standard error. Don't write error messages to standard out—write them to standard error.

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!
...presumably, this will also be a performance hit because of the overhead of running Bash.

I would strongly advise you not to use sys calls unless you are calling a very complex external application that would be difficult to reproduce in your C code in reasonable time and doesn't have a C API (and serious applications are not generally written in Bash) or you are performing an extremely low-level function that there is no C API for. Work for homogeneity—it's much cleaner.

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!
...presumably, this will also be a performance hit because of the overhead of running Bash.

deleted 29 characters in body

Source Link

edited Feb 2, 2013 at 7:16

seand

edited Feb 2, 2013 at 7:16

seand

2.5k
1
20
29

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

I would strongly advice you not to seriously advise you not to use sys calls unless you are calling a very complex external application that would be difficult to reproduce in your C code in reasonable time and doesn't have a C API (and serious applications are not generally written in Bash) or you are performing an extremeltyextremely low-level function that there is no C API for. Work for homogeneity—it's much cleaner.

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

I would strongly advice you not to seriously advise you not to use sys calls unless you are calling a very complex external application that would be difficult to reproduce in your C code in reasonable time and doesn't have a C API (and serious applications are not generally written in Bash) or you are performing an extremelty low-level function that there is no C API for. Work for homogeneity—it's much cleaner.

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

Added more on general cleanliness, etc

Source Link

edited Feb 2, 2013 at 2:02

Kazark

edited Feb 2, 2013 at 2:02

Kazark

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

I would strongly advice you not to seriously advise you not to use sys calls unless you are calling a very complex external application that would be difficult to reproduce in your C code in reasonable time and doesn't have a C API (and serious applications are not generally written in Bash) or you are performing an extremelty low-level function that there is no C API for. Work for homogeneity—it's much cleaner.

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.

Comments

Functions

Magic Numbers

Replace numbers like -1 and 10 in your code with a constant that has an explicit name explaining these numbers. This increases the readability and maintainability of your code.

Stdout and Stderr

Calling Bash from C

Consider that calling Bash...

...makes your code much, much less portable, by tying it down to a system with Unix utilities—and more specifically than that, one that has Bash—and more than that, one that has a version of Bash which supports all the features you decide to use.
...makes your code harder to test

by creating external dependencies. If you are not familiar with the problem of dependencies, try reading up on it. Roy Osherove, in The Art of Unit Testing, and Michael Feathers, in Working Effectively with Legacy Code, both have much discussion of it.
Bash scripts do not have the debugging tools for than that C has (Valgrind, GDB, IDEs, etc).

...makes your code harder to read:

by lessening its homogeneity
by making the user move around move between various source files
by lessening your IDE's ability to aid you in traversing the code, since some of the calls are embedded in strings as calls to an external
because Bash is often even harder to read than C

...makes your code harder to maintain, because of being harder to test and read.
...is unnecessary, because under the covers Bash is just calling the Unix C API anyway.
...is artistically distasteful— it smells like a kludge.
...adds a failure point to your code. Just look how many possible error messages you output, and then abort!

I would strongly advice you not to seriously advise you not to use sys calls unless you are calling a very complex external application that would be difficult to reproduce in your C code in reasonable time and doesn't have a C API (and serious applications are not generally written in Bash) or you are performing an extremelty low-level function that there is no C API for. Work for homogeneity—it's much cleaner.

Source Link

answered Feb 2, 2013 at 1:44

Kazark

answered Feb 2, 2013 at 1:44

Kazark

default