On Wed, May 28, 2014 at 12:30 PM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 2014-05-28 17:43, Gedare Bloom wrote: >>> >>> We still have no new rule for "avoidance of deep nesting by using early >>> >returns" in the wiki page. So we are still in the situation that >>> > everyone >>> >interested in code contributions must deduce this rule himself from the >>> >"almost 200 API calls which take object ID and have the _Object_Get() >>> >switch". >>> > >> >> My vote is to limit nesting to 4 levels of indentation. Early returns >> or local goto to error/out label should be used when it makes sense. >> For example: >> int foo(int bar) >> { >> int a = 0; // one level >> if ( bar == a ) { >> int b = 1; // two levels >> while ( a++ < b ) { >> int c = 2; // three levels >> if ( a == c ) { >> goto err; // fourth and deepest level! >> } >> } >> } >> return 0; >> err: >> return -1; >> } >> > > For the cpukit the coding style should enforce that new/changed code looks > similar enough to the exiting code. I really don't care how particular > rules look like since you can find for every rule an arbitrary amount of > pros and cons. I think however that it is very important that the rules in > charge are documented. I should be possible to give newcomers a document > that describes the coding style in detail. It can also be used to judge > code contributions. > > A "avoidance of deep nesting by using early returns" rule should cover what > happens if it leads to duplicated clean up code. > I agree completely. My main point is that I don't know what "deep" means here. You can always refactor code to reduce the depth to 1 nesting level, but no one wants that either. I guess what is the prevailing sense of the nesting level we have/want?
-Gedare > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel