Principles for C programming
drewdevault.com
Principles for C programming
1–10 of 149 posts
Re: Principles for C programming
#2These points may be especially important for C programming, but most of them really apply to programming in any language.
Re: Principles for C programming
#3Feels too heavy on "donts." I imagine the motivation the desire to be heard and understood. But I also need something simple, like "keep it simple, stupid" or "first have a working product that anyone could read". Positivity >> negativity.
Re: Principles for C programming
#4All sounds good in theory but in practice in a large enough project many of the suggestions are not practical.
Recently I was looking at rsyslog's source code.
Look at this "simple" file for example, https://github.com/rsyslog/rsyslog/blob/master/plugins/omstd...
It's an output module for rsyslog that logs to stdout.
I wanted to gouge my eyes out.
Re: Principles for C programming
#5All sounds good in theory but in practice in a large enough project many of the suggestions are not practical. Recently I was looking at rsyslog's source code. Look at this "simple" file for example, https://github.com/rsyslog/rsyslog/blob/master/plugins/omstd... It's an output module for rsyslog that logs to stdout. I wanted to gouge my eyes out.
This code fails to follow many of my suggestions.
- Liberal use of macros
- Horribly unreadable coding style
- Needless use of compiler extensions
- Very poorly organized code
This is awful code because the authors are morons, not because the language is bad. They could stand to read this blog post.
Re: Principles for C programming
#6All sounds good in theory but in practice in a large enough project many of the suggestions are not practical. Recently I was looking at rsyslog's source code. Look at this "simple" file for example, https://github.com/rsyslog/rsyslog/blob/master/plugins/omstd... It's an output module for rsyslog that logs to stdout. I wanted to gouge my eyes out.
This code fails to follow many of my suggestions. - Liberal use of macros - Horribly unreadable coding style - Needless use of compiler extensions - Very poorly organized code This is awful code because the authors are morons, not because the language is bad. They could stand to read this blog post.
I'd say that's a bit naive.
How would you go about writing something like rsyslog without doing the things they have done?
How would you create rsyslog's flexible (I'm not saying it's "good") module system where people can write their own pluggable custom input/output modules?
Your comment somehow suggests that it's possible to achieve everything they have achieved in terms of functionality while doing it in a much much better way that they just don't know about.
If people writing rsyslog aren't good enough to do it then 99% of other people aren't either.
So let's not blame people, it's the weakness of the language.
Re: Principles for C programming
#7Feels too heavy on "donts." I imagine the motivation the desire to be heard and understood. But I also need something simple, like "keep it simple, stupid" or "first have a working product that anyone could read". Positivity >> negativity.
I guess there are 'donts' because people need help with the keep it simple part, they are quite comfortable with the stupid part.
Re: Principles for C programming
#8>Do not use macros. Do not use a typedef to hide a pointer or avoid writing “struct”. Avoid writing complex abstractions. Keep your build system simple and transparent. Don’t use stupid hacky crap just because it’s a cool way of solving the problem.
Heh, good luck avoiding the use of macros in sufficiently complex projects - sometimes C just can't use some control structures in an elegant manner without using macros or custom abstractions.
Re: Principles for C programming
#9Earlier quoted context omitted.
This code fails to follow many of my suggestions. - Liberal use of macros - Horribly unreadable coding style - Needless use of compiler extensions - Very poorly organized code This is awful code because the authors are morons, not because the language is bad. They could stand to read this blog post.
I'd say that's a bit naive. How would you go about writing something like rsyslog without doing the things they have done? How would you create rsyslog's flexible (I'm not saying it's "good") module system where people can write their own pluggable custom input/output modules? Your comment somehow suggests that it's possible to achieve everything they have achieved in terms of functionality while doing it in a much m…
Are you serious? You could start by fixing that godawful code style and removing the macros. You could change these variable names and function names to make more sense (CHKiRet? omsdRegCFSLineHdlr? What the hell?). The compiler extensions are unnecessary and can just be removed. None of these changes have any impact on the functionality of rsyslog.
Re: Principles for C programming
#10Feels too heavy on "donts." I imagine the motivation the desire to be heard and understood. But I also need something simple, like "keep it simple, stupid" or "first have a working product that anyone could read". Positivity >> negativity.
I guess there are 'donts' because people need help with the keep it simple part, they are quite comfortable with the stupid part.
"nobody's grading your code by how many abstractions and topics from a textbook it employs."