On 11/17/2016 05:43 PM, Daniel Mihai via iotivity-dev wrote:
>>> Dan, for the 100 lines of code, do we need them fragmented? What happen we
>>> enforce them use common code?
>
> Example for what I had in mind:
>
>
>
> voidfoo1()
> {
> int a, b, c;
>
> // 20 lines of non-optional code that calculate the values of a, b and c
>
>
> #ifdefMY_OPTIONAL_FEATURE
> // 100 lines of optional code that is using a, b, c
> #endif
>
> // 20 lines of non-optional code that is using a, b and c
> }
>
> Sometimes it might be preferable to change that to:
>
> voidfoo2()
> {
> inta, b, c;
>
> // 20 lines of non-optional code that calculate the values of a, b and c
>
> #ifdefMY_OPTIONAL_FEATURE
> MyOptionalFunction(a, b, &c);
> #endif
>
> // 20 lines of non-optional code that is using a, b and c
> }
>
> voidMyOptionalFunction(inta, intb, int*c)
> {
> // 100 lines of optional code that is using a, b, c
> }
>
> The second version of foo() can be useful, because even without being
> familiar with the optional feature, I can infer quickly that:
> - the optional feature will not change the values of a and b
> - the optional feature might change the value of c
I'd even propose that when we can arrange it, these optional in-development
features be exposed (not #ifdef'd) but protected by a runtime feature-test
during most of the development cycle. That would mean it's always being
compiled and can't rot as other code evolves for the developers (presumably the
majority) who aren't forcing the #define during their builds - as well as the
automated builds, etc. Being able to turn those off completely at release time
would be a safety feature we could still do.
