2 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem: http://programmers.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-themhttps://softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.

Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem: http://programmers.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.

Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem: https://softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.

1
source | link

Not sure if you can call this a best-practice. When I set up guidelines for a new C project I always state that it is better to declare the variables close to where they are used. For two reasons, it makes it easier to refactor the code later on (i.e. when extracting a method). It also helps the compiler to do better optimization.

I'm not alone with this opinion. Here's a question that tackles the same problem: http://programmers.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need-them The answer here is to declare them where you use them. The same practice is described in the book 'Clean Code' by Robert C. Martin.

However, if you use an older C-standard (C-89), you must define local variables at the top of the function. So maybe the guideline is a remnant from the time when C-89 was used? It is probably better to ask the person that wrote the guidelines why the rule is still in there.