> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com] > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > > > 10/06/2024 18:31, Konstantin Ananyev: > > > > Morten said: > > > > > The coding style guide says: > > > > > > > > > > "Variables should be declared at the start of a block of code rather > than > > > in the middle. The exception to this is when the variable is > > > > > const in which case the declaration must be at the point of first > > > use/assignment. Declaring variable inside a for loop is OK." > > > > > > > > > > Since DPDK switched to C11, variables can be declared where they are > used, > > > which reduces the risk of using effectively uninitialized > > > > > variables. "Effectively uninitialized" means initialized to 0 or NULL > > > where declared, to silence any compiler warnings about the use of > > > > > uninitialized variables. > > > > > > > > > > Can we please agree to remove the recommendation/requirement to > declare > > > variables at the start of a block of code? > > > > > > > > I know that modern C standards allow to define variable in the middle. > > > > But I am strongly opposed to allow that in DPDK coding style. > > > > Such practice makes code much harder to read and understand (at least > for > > > me). > > > > > > Yes it is convenient to know that all variables are described > > > in a known place, just after function parameters. > > > > > > There is also a consistency concern. > > > > > > Old contributors like to be in a comfort zone, > > > and we don't want to lose old contributors. > > > New contributors may be refrained by old rules, > > > and we would like to get more new contributors. > > > > > > So that's a tricky decision. > > > > > > > Independent research shows that readability is improved by declaring local > variables as close as possible to their first use: > > https://barrgroup.com/72-initialization#footnote12
The footnote refers to [Uwano], which can be found here: [Uwano]: https://www.cs.kent.edu/~jmaletic/Prog-Comp/Papers/Uwano06.pdf > > Hmm... seems they don't provide any data to back up their statements. > Specially that one sounds weird for me: > " Too many programmers assume the C run-time will watch out for them, e.g., by > zeroing the value of uninitialized variables on system startup." > Why on earth people would assume that? Not all programmers remember all the rules all the time. Especially junior developers. > And what exactly means 'too many? 1%? 10%? 90%? I guess that "too many" means that it is a statistically significant cause of bugs. PS: I like your way of reasoning. I guess the Barr Group is trying to keep it short in their handbook, omitting the details from the underlying research. It's a shame Jack Ganssle stopped giving his "How to Develop Better Firmware Faster" seminar (https://www.ganssle.com/classes.htm). All his "rule-of-thumb" guidelines are backed with hard data from references and experiments! > > > > > Old people (like myself) need to unlearn their bad old habits (originating > from limitations in old C standards), and embrace modern > > methods to reduce the risk of introducing bugs. > > Allowing to define variables in the middle of the code by itself wouldn't > prevent of use of un-initialized variables. > From other side - compilers are quite good these days to catch such bugs. > So I don't think it is a completing argument.. Please note that I am talking about "effectively uninitialized" variables, meaning variables that have been initialized with dummy values like NULL, 0 or -1, only to make the "use of uninitialized variable" compiler warnings go away. Initializing variables with dummy values effectively disables the compiler's ability to catch bugs where a variable is being used before it has been assigned a (correct) value, because the compiler cannot know that the variable has been initialized with a dummy value. The advantages of declaring the variable where it is used the first time are: - The developer is much likelier to assign it the correct value to begin with. - The reviewer is much likelier to spot if it is initialized with an incorrect value.
