#1617 Coding style deviation in ding-libs
Closed: Invalid None Opened 11 years ago by dpal.

INI and collection use

    if (condition) {
        /* do some work */
    }
    else {
        /* do some other work */
    }

While the coding guide suggests use of:

    if (condition) {
        /* do some work */
    } else {
        /* do some other work */
    }

Fields changed

summary: Codinbg style deviation in ding-libs => Coding style deviation in ding-libs

Fields changed

summary: Codinbg style deviation in ding-libs => Coding style deviation in ding-libs

Fields changed

summary: Codinbg style deviation in ding-libs => Coding style deviation in ding-libs

Fields changed

owner: somebody => okos

Fields changed

owner: somebody => okos

Fields changed

owner: somebody => okos

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

Fields changed

rhbz: => 0

I reviewed the code of the ding libs.
There are several hundreds of the cases where this rule of the style is violated.
I tried fixing couple places and find it lass readable.
For example the following code seems more readable:

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    }
    else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        }
        else error = EOK;
    }

than this one

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    } else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        } else error = EOK;
    }

Since it is not a critical aspect I lean to closing this ticket as wontfix.

resolution: => wontfix
selected: =>
status: new => closed

I reviewed the code of the ding libs.
There are several hundreds of the cases where this rule of the style is violated.
I tried fixing couple places and find it lass readable.
For example the following code seems more readable:

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    }
    else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        }
        else error = EOK;
    }

than this one

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    } else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        } else error = EOK;
    }

Since it is not a critical aspect I lean to closing this ticket as wontfix.

resolution: => wontfix
selected: =>
status: new => closed

I reviewed the code of the ding libs.
There are several hundreds of the cases where this rule of the style is violated.
I tried fixing couple places and find it lass readable.
For example the following code seems more readable:

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    }
    else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        }
        else error = EOK;
    }

than this one

    if (!data) {
        TRACE_ERROR_STRING("Invalid argument", "");
        error = EINVAL;
    } else {
        *data = (struct simplebuffer *)calloc(1,
                                              sizeof(struct simplebuffer));
        if (*data == NULL) {
            TRACE_ERROR_STRING("Failed to allocate memory", "");
            error = ENOMEM;
        } else error = EOK;
    }

Since it is not a critical aspect I lean to closing this ticket as wontfix.

resolution: => wontfix
selected: =>
status: new => closed

Metadata Update from @dpal:
- Issue assigned to okos
- Issue set to the milestone: Tools 1.0

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2659

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata