MCU (Embedded C): Use nested if/elses or use an ugly function?
The variable names in both of those snippets are absolutely insane! But at least it seems clear on close inspection that ENA and DIS are abbreviations of "enable" and "disable." I would write those out.

I would rewrite the instructor's code like this:

typedef uint8_t EnableStatus;

void SPI_EnablePeripheralClock1(EnableStatus status) {
    if (status) {
        RCC-&gt;APB2ENR |= (1 &lt;&lt; 12);
    } else {
        RCC-&gt;APB2ENR &amp;= ~(1 &lt;&lt; 12);
    }
}

void SPI_EnablePeripheralClock2(EnableStatus status) {
    if (status) {
        RCC-&gt;APB1ENR |= (1 &lt;&lt; 14);
    } else {
        RCC-&gt;APB1ENR &amp;= ~(1 &lt;&lt; 14);
    }
}

void SPI_EnablePeripheralClock(SPI_RegDef_t *pSPI, EnableStatus status) {
    switch (pSPIx) {
        case SPI1: SPI_EnablePeripheralClock1(status); break;
        case SPI2: SPI_EnablePeripheralClock2(status); break;
        default: assert(false); break;  // what goes here?
    }
}


But it really depends on how this SPI_EnablePeripheralClock function is going to be used "upstream" in the caller. For example, why is EnableStatus a typedef for uint8_t instead of bool?

In fact, I would be tempted to write two convenience functions with English names:

void EnablePeripheralClock() {
    SPI_EnablePeripheralClock(&amp;spi, true);
}
void DisablePeripheralClock() {
    SPI_DisablePeripheralClock(&amp;spi, false);
}


Alternatively, it might make sense to refactor along those lines from the very beginning...

void EnablePeripheralClock() {
    switch (pSPIx) {
        case 1: RCC-&gt;APB2ENR |= (1 &lt;&lt; 12); break;
        case 2: RCC-&gt;APB1ENR |= (1 &lt;&lt; 14); break;
        default: assert(false);
    }
}

void DisablePeripheralClock() {
    switch (pSPIx) {
        case 1: RCC-&gt;APB2ENR &amp;= ~(1 &lt;&lt; 12); break;
        case 2: RCC-&gt;APB1ENR &amp;= ~(1 &lt;&lt; 14); break;
        default: assert(false);
    }
}


Here we're breaking down the code from the top down, focusing on "what task needs accomplishing" (e.g. "disable the clock"), rather than taxonomizing from the bottom up. Of course it's hard to know if we've done it right, when we don't know what top-level tasks need accomplishing. :)