Hallo zusammen, da sich hier doch einige aufhalten, die Ahnung von Programmierung und C haben, hier ein kleines Anliegen:

Ich habe ein einfaches Programm in C geschrieben, dass man per Kommandozeile und 1 zusätzlichen Parameter ausführen kann. Übergeben wird der Name einer Textdatei und das Programm zählt die Häufigkeit vorkommender Zahlen im Text und gibt die abs./rel. Häufigkeit aus.

Hier der Code:
Quellcode:#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

#define SIZE    10

void print_digits(int *pDig, int n);

int main(int argc, char *argv[]) {
    if(argc != 2) {
        printf("Usage: %s <textfile>\n", argv[0]);
        return EXIT_FAILURE;
    } else {
        FILE *pFile;
        pFile = fopen(argv[1], "r");
        if(pFile == NULL) {
            printf("Couldn't load \'%s\'.\n", argv[1]);
            return EXIT_FAILURE;
        } else {
            int ch;
            int count = 0;
            int *pDigits = (int*) calloc(SIZE, sizeof(int));
            if(pDigits == NULL) {
                printf("Couldn't allocate memory.\n");
                fclose(pFile);
                return EXIT_FAILURE;
            }
            while((ch = fgetc(pFile)) != EOF) {
                if(isdigit(ch)) {
                    count++;
                    pDigits[ch-'0']++;
                }
            }
            if(count != 0) {
                printf("File \'%s\' contains %d digits:\n", argv[1], count);
                print_digits(pDigits, count);
            } else
                printf("File \'%s\' contains no digits.\n", argv[1]);
            free(pDigits);
            fclose(pFile);
        }
    }
    return 0;
}

void print_digits(int *pDig, int n) {
    int i;
    for(i = 0; i < SIZE; i++)
        printf("* %d: %6d %6.2f%%\n", i, pDig[i], (float)pDig[i]/n*100);
}
Klappt auch alles und es tut, was es soll. Nun meine Fragen, die nicht unbedingt auf technische Aspekte eingehen:

- Ist der Aufbau so in Ordnung?
- Wo könnte es Schwachstellen geben, was könnte man besser/übersichtlicher schreiben?
- Was gibt es generell zu verbessern?
- argv[0] ok, oder lieber separates char* pName benutzen?
- mehr Funktionen benutzen?

Zum Beispiel:
Was wäre besser: erste Variante mit großer else-Anweisung oder die Zweite nur mit kurzer if-Abfrage?

Quellcode:// 1ste Variante:
main() {
  FILE *pFile;
  pFile = fopen("text.txt", "r");
  if(pFile == NULL) {
    //error -> exit
  } else {
    // viele Anweisungen
    fclose(pFile);
  }
}
// 2te Variante:
main() {
  FILE *pFile;
  pFile = fopen("text.txt", "r");
  if(pFile == NULL) {
    //error -> exit
  }
  // viele Anweisungen
  fclose(pFile);
}
Um solche Dinge geht es. Hoffentlich nicht zu viel, Danke :)

Zitat:

- Wo könnte es Schwachstellen geben, was könnte man besser/übersichtlicher schreiben?

Zitat:

Was wäre besser: erste Variante mit großer else-Anweisung oder die Zweite nur mit kurzer if-Abfrage?

Zitat:

- Was gibt es generell zu verbessern?

Zitat:

Quellcode:/* ... */
            if(count != 0) {
                printf("File \'%s\' contains %d digits:\n", argv[1], count);
                print_digits(pDigits, count);
            } else
                printf("File \'%s\' contains no digits.\n", argv[1]);


Zitat:

- argv[0] ok, oder lieber separates char* pName benutzen?

Zitat:

- mehr Funktionen benutzen?

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Quellcode:if(pDigits == NULL) { Dieser Schnippsel wird bei einem Tippfehler zu einem Fehlverhalten fuehren und dennoch sauber kompilieren. Es macht meiner Meinung nach mehr Sinn R-Values auf die linke Seite Vergleichsoperators schreiben, dann nimmt sich der Kompiler der Sache an.

Quellcode:if(NULL == pDigits) { Ausserdem solltest du entweder immer die Ungarische Notation nutzen oder nie, aber nicht ab und zu. (pDigits, pFile, pDig im Gegensatz zu ch, count). Das gleiche gilt auch fuer EXIT_FAILURE, fuer welches es auch das Gegenstueck EXIT_SUCCESS gibt.

Auch stossen mir die verstuemmelten Variablennamen und die namenlose Schleifenvariable in print_digits auf.

There is nothing wrong with high standards. It's your problem that you don't meet them.
If you think it's simple, then you have misunderstood the problem.
When a customer says "nothing has changed", assume they're lying.

Quellcode:if(count != 0) Sowas kann man reduzieren auf die Implizierung
Quellcode:if(count) Ansonsten gebe ich Bluthund recht, wenn er die "mangelhafte" Formatierung des Quellcodes anprangert. Ich persönlich formatiere Blöcke bspw. so:
Quellcode:if(abc != xyz)
{
    ...
}
else
{
    ...
} Imho das übersichtlichste Verfahren. Man muß nur konsequent bleiben ;)

@Adrian_Broher: Das Vertauschen des R-Values nach Links raubt der Aussage aber den Sinn: Wenn pDigits gleich NULL ist... Bei dir würde es dann bedeuten: Wenn NULL gleich pDigits ist... NULL ist Nullzeiger per Definition, wieso sollte es auf Gleichheit mit dem Inhalt eines x-beliebigen Zeigers getestet werden? Das sorgt im semantischen Grunde für mehr Verwirrung als nötig, und C ist nicht immer von Haus aus wirrenfrei für Anfänger. Es ist ja nicht falsch, aber unnötig. Ansonsten würde hier auch die Implizierung greifen
Quellcode:if(!pDigits)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Vielen Dank für eure beiden Antworten, genau das, was ich gehofft hatte zu lesen!

Zu Bluthund:

Zitat:

Bluthund postete

Zitat:

- Wo könnte es Schwachstellen geben, was könnte man besser/übersichtlicher schreiben?

Leerzeilen! Versuche den Code auch optisch zu strukturieren.
Dadurch dass du keine Leerzeilen verwendest und den Code in "Java-Style" (K&R mit Brace auch hinter dem Funktionskopf) geschrieben hast, mutiert das Ganze zu einem "riesigen" Textklumpen, der schnell schwierig zu ueberfliegen wird, weil sich dabei eigentlich nur die Blockenden ueberhaupt heraus heben.
Jeweils eine Leerzeile vor und nach Kontrollstrukturen zu positionieren hilft der Uebersichtlichkeit in den meisten Faellen ungemein.

Zitat:

Bluthund postete

Zitat:

Was wäre besser: erste Variante mit großer else-Anweisung oder die Zweite nur mit kurzer if-Abfrage?

Da du den ersten Zweig immer mit einem return verlaesst (guard clause), gibt es eigentlich keine Rechtfertigung dafuer den Rest des Codes in den else-Zweig zu stopfen und damit unnoetig tief einzuruecken. Daher meine Empfehlung: nimm die zweite Variante.
Zu tiefe Einrueckung ist meist naemlich u.a. ein guter Indikator dafuer, dass eine Funktion viel zu viel tut und in mehrere Funktionen aufgeteilt werden sollte. Das sollte in so einem simplen Programm aber nicht der Fall sein. (Du haettest eigentlich sogar noch eine Stufe tiefer einruecken muessen wenn du konsistent else nach guard clauses eingesetzt haettest. Du benutzt naemlich bei der Pruefung von argc und pFile Variante 1 aber nach dem calloc von pDigits Variante 2.)

Zitat:

Bluthund postete

Zitat:

- Was gibt es generell zu verbessern?

Fehler gehoeren auf die Standardfehlerausgabe (stderr via fprintf) und nicht auf stdout (via printf).
Der Rueckgabewert von malloc (wie auch der seiner Brueder calloc und realloc) sollte in C nicht direkt auf den Zieltyp gecastet werden, um zu vermeiden, dass Compilerfehler bei fehlender Header-Inkludierung unterdrueckt werden (C hat implizite Funktionsdeklaration).
Hilf deinem Compiler ein bisschen und ersetze die post-increments durch pre-increments wenn du den alten Wert der Variable von vor der Inkrementierung nicht benoetigst.

Quellcode:int *pDigits;
pDigits  = (int*) calloc(SIZE, sizeof(int));
Eben wie bei Schleifen, dass die Laufvariable vor dem Schleifenkopf deklariert wird. Habe ich hoffentlich so richtig verstanden.

Zitat:

Bluthund postete

Zitat:

- argv[0] ok, oder lieber separates char* pName benutzen?

Bringt eigentlich keinen Gewinn fuer die Leserlichkeit. Dass in argv[0] in main() der Programmname steht, sollte eigentlich jeder wissen, der sich C-Quellen anschaut.
Auch die direkte Nutzung von argv[1] in so einem trivialen Programm mit nur einem Parameter ist eigentlich voellig ok.

Zitat:

Bluthund postete
Vorschlag daher (wenn die Funktion denn drin bleiben soll):
Quellcode:void print_frequencies(int *freqArray, size_t size, int total_count)
{
    for (int i = 0; i < size; ++i) {
        printf("* %d: %6d %6.2f%%\n", i, freqArray[i], (float)freqArray[i]/total_count*100);
    }
}

Gernerell muss ich an der Konsequent der Braces und der Namensgebung wohl noch arbeiten und beides verbessern (vor allem sinnvollere Namen) und du hast du recht, dass man an der Funktions-Implementierung leicht in die Irre geführt wird und es nicht klar ist, was die Funktion bewerkstelligt. Die Sache mit dem size_t werde ich mir noch ansehen. Ganz davon abgesehen, ob die Funktion im Rahmen der Größe überhaupt Sinn macht.

Zu Adrian:

Zitat:

Adrian_Broher postete
Quellcode:if(pDigits == NULL) { Dieser Schnippsel wird bei einem Tippfehler zu einem Fehlverhalten fuehren und dennoch sauber kompilieren. Es macht meiner Meinung nach mehr Sinn R-Values auf die linke Seite Vergleichsoperators schreiben, dann nimmt sich der Kompiler der Sache an.
Quellcode:if(NULL == pDigits) {

Zitat:

Adrian_Broher postete
Ausserdem solltest du entweder immer die Ungarische Notation nutzen oder nie, aber nicht ab und zu. (pDigits, pFile, pDig im Gegensatz zu ch, count). Das gleiche gilt auch fuer EXIT_FAILURE, fuer welches es auch das Gegenstueck EXIT_SUCCESS gibt.

Hoffe ich habe keinen Aspekt übersehen und alles angesprochen, noch mal großes Danke!

Zu Kriz:

Zitat:

Kriz postete
Quellcode:if(count != 0) Sowas kann man reduzieren auf die Implizierung
Quellcode:if(count)

Zitat:

Kriz postete
Ansonsten gebe ich Bluthund recht, wenn er die "mangelhafte" Formatierung des Quellcodes anprangert. Ich persönlich formatiere Blöcke bspw. so:
Quellcode:if(abc != xyz)
{
    ...
}
else
{
    ...
} Imho das übersichtlichste Verfahren. Man muß nur konsequent bleiben ;)

Auch dir Danke!

Und noch eine kurze Frage: Alle Variablen generell unmittelbar nach Einstieg in main() deklarieren (weil ggf. übersichtlicher) oder erst nach und nach? Einfaches Beispiel:

Quellcode:/* 1ste: */
main()
{
    int i;
    /* und alle anderen Veriablen */

    /* viele andere Anweisungen, die auch zum vorzeitigen Abbruch führen könnten */

    for(i = 0; i < n; ++i)
    {
        /* Ausgabe */
    }
}

/* 2te: */

main()
{
    /* viele andere Anweisungen, die auch zum vorzeitigen Abbruch führen könnten */

    int i;    
    for(i = 0; i < n; ++i)
    {
        /* Ausgabe */
    }
}


Auch auf die Gefahr hin, dass es so langsam unübersichtlich werden könnte: hier ein ähnlich kurzer Code, mit dem Unterschied, dass er die Häufigkeit von Buchstaben auswertet. Vielleicht gibt es noch Ungereimtheiten, aber die Art und Weise gefällt mir nun schon deutlich besser, vor allem die doch recht solide Übersichtlichkeit und Gliederung:

Quellcode:#include <stdio.h>
#include <ctype.h>
#include <stdlib.h>

#define    SIZE    26

int main(int argc, char *argv[])
{
    /* Variablen anfänglich deklarieren?
    FILE *pFile;
    int nChar;
    int nTotal = 0;
    int *pLetters;
    */

    if(argc != 2)
    {
        fprintf(stderr, "Usage: %s <textfile>\n", argv[0]);    /* so richtig? */
        return EXIT_FAILURE;
    }

    FILE *pFile;
    pFile = fopen(argv[1], "r");
    
    if(!pFile)
    {
        fprintf(stderr, "Couldn't load \'%s\'.\n", argv[1]);
        return EXIT_FAILURE;
    }

    int *pLetters;
    pLetters = (int*) calloc(SIZE, sizeof(int));

    if(!pLetters)
    {
        fprintf(stderr, "Couldn't allocate memory.\n");
        fclose(pFile);
        return EXIT_FAILURE;
    }

    int nChar; /* ungluecklicher Name? */
    int nTotal = 0;

    while((nChar = fgetc(pFile)) != EOF)
    {
        if(isalpha(nChar))
        {
            ++nTotal;
            if(isupper(nChar))
            {
                ++pLetters[nChar-'A'];
            }
            else if(islower(nChar))
            {
                ++pLetters[toupper(nChar)-'A'];
            }
        }
    }

    fclose(pFile);

    printf("* Statistic of \'%s\':\n", argv[1]);
    printf("* Total letters: %d\n", nTotal);
    printf("* Overview:\n");

    int i;
    for(i = 0; i < SIZE; ++i)
    {
        if(pLetters[i] != 0)
        {
            printf("%c: %6d %6.2f%%\n", (char)i+'A', pLetters[i], (float)pLetters[i]/nTotal*100);
        }
    }

    free(pLetters);

    return EXIT_SUCCESS;
}


Zitat:

Wegen calloc sollte der Code wohl so aussehen:

Quellcode:int *pDigits;
pDigits  = (int*) calloc(SIZE, sizeof(int)); Eben wie bei Schleifen, dass die Laufvariable vor dem Schleifenkopf deklariert wird. Habe ich hoffentlich so richtig verstanden.

Zitat:

Und noch eine kurze Frage: Alle Variablen generell unmittelbar nach Einstieg in main() deklarieren (weil ggf. übersichtlicher) oder erst nach und nach?

Quellcode:else if(islower(nChar))
{
    ++pLetters[toupper(nChar)-'A'];
} *buzz* Arraygrenze ueberschritten. Sollte wohl -'a' sein.
Nutzung von fprintf passt. Ausser fuer die Usage-Meldung. Die sollte kein Fehler sein sondern eine normale Ausgabe. Der Fehler an der Stelle waere etwas wie "Zu wenig/viele Argumente".

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Zitat:

Bluthund postete
[...] Gemeint war es so:
Quellcode:int *pDigits = calloc(SIZE, sizeof(int)); Hier geht es nicht um Konsistenz sondern um Fehlervermeidung. Wenn du naemlich den entsprechenden Header nicht inkludierst (im konkreten Fall stdlib.h) baut dir C automatisch bei der ersten Verwendung einer Funktion einen Prototypen fuer diese zusammen falls noch keiner existiert. Und diese Prototypen geben int zurueck. Wenn du jetzt explizit castest (via (int*)) denkt der Compiler du weisst was du da tust. Dummerweise kannst du in C alles wild umher casten sobald Pointer involviert sind. Also auch int nach int* (bei einer 64bit-Kompilierung wuerde das hoechstens eine Warnung ausspucken, dass die beiden Typen nicht gleich breit sind).
Neuere Compiler wie der gcc 4.4 spucken zusaetzlich noch eine Warnung wenn "built-in functions" mit abweichender Signatur definiert werden (egal ob implizit oder explizit). Das Ganze kompiliert und linkt gegen die libc bzw. CRT aber einwandfrei und kann je nach Plattform bei der Ausfuehrung funktionieren, nicht funktionieren oder deine Nachbarschaft abbrennen.

Zum Problem der Variablendefinition: werde es dann wie in der zweiten Variante halten und die "Live-Time" bzw den Scope der betreffenden Variable beachten und die Variable ggf. am Anfang oder zum passenden Zeitpunkt erstellen. Also nach C99. Und auch Schleifenvariablen künftig anders handhaben und erst im Schleifenkopf definieren, außer es tritt zum Beispiel die von dir bereits genannte Ausnahme (break oder vergleichbares) auf.

Begriffe libc bzw. CRT habe ich schon mal gehört, sagen mir aber gerade nicht wirklich viel, wird auch nachgeschlagen. Die Liste wird stetig länger ;)

Zitat:

Bluthund postete
Quellcode:else if(islower(nChar))
{
    ++pLetters[toupper(nChar)-'A'];
} *buzz* Arraygrenze ueberschritten. Sollte wohl -'a' sein.
Nutzung von fprintf passt. Ausser fuer die Usage-Meldung. Die sollte kein Fehler sein sondern eine normale Ausgabe. Der Fehler an der Stelle waere etwas wie "Zu wenig/viele Argumente".

Danke :)

Oh stimmt, toupper() hatte ich uebersehen (weil nicht erwartet). Das funktioniert natuerlich.
Aber warum noch eine Funktion rufen wenn man auch einfach direkt mit dem Wert rechnen kann den man schon hat ;)
Quellcode:++pLetters[nChar-'a']; [edit]oder direkt die komplette Verzweigung weglassen und beide Faelle durch
Quellcode:if (isalpha(nChar)) {
    ++nCount;
    ++pLetters[tolower(nChar)-'a']; // toupper(nChar)-'A' funktioniert natuerlich auch.
} abdecken.[/edit]
libc und CRT bezeichnen die C-Standard-Bibliothek (libc im unixoiden Umfeld (glibc bei GNU) und CRT [C Runtime] bei MS)

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Stimmt, da hast du Recht, toupper() ist in diesem Fall überflüssig. Mit ++pLetters[nChar-'a']; geht es natürlich einwandfrei, Denkfehler meinerseits. Danke für deine echt ausführliche Hilfe :)

Edit:

Zitat:

Bluthund postete
Quellcode:if (isalpha(nChar)) {
    ++nCount;
    ++pLetters[tolower(nChar)-'a'];
    /* tolower, da wahrscheinlich mehr Kleinbuchstaben im Text vorkommen
     * und damit je nach Implementierung von tolower() der Aufruf in den
     * meisten Faellen "schneller" zurueckkehrt
     */
}

"Optimal" und "schoen" liegen immer im Auge des Betrachters :)
Der gemeine C-Hacker oder Leute mit extremen Anforderungen an die Ausfuehrungsgeschwindigkeit (Stichwort Embedded Systeme) wuerden wahrscheinlich lieber sowas sehen:
Quellcode:++pLetters[nChar-'A' & ~0x20]; /* 'A' extremely readable, consider using 0x41 */ ;)
edit: oderQuellcode:++pLetters[--nChar & ~0x60];

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Wow, nicht schlecht :)
Bit-Operatoren kenne ich zwar, aber kamen bei mir noch nie wirklich zum Einsatz, auf jeden Fall interessant (und lehrreich) zu sehen. Bis zum gemeinen C-Hacker wird es also noch dauern ;)

Zitat:

Bluthund postete
Hilf deinem Compiler ein bisschen und ersetze die post-increments durch pre-increments wenn du den alten Wert der Variable von vor der Inkrementierung nicht benoetigst.

1. Jeder Compiler optimiert das sowieso, so dass post-increment und pre-increment hier äquivalent sind. Wenn dem nicht so ist, kann man das getrost als Bugreport melden.

2. Selbst wenn der Compiler das nicht optimieren würde, wäre diese Art der Optimierung hier völlig daneben (siehe meine Signatur).

Davon einmal abgesehen: Es ist tatsächlich nicht verkehrt, sich pre-increments anzugewöhnen. Wenn man nämlich irgendwann einmal C++ programmieren sollte und damit überladene operator++ verwendet (z.B. bei Iteratoren) kann man tatsächlich in eine Situation kommen, in der der Compiler den Unterschied zwischen post- und pre-increment nicht mehr wegoptimieren kann.

Also wie gesagt, pre-increments sind eine feine Sache, aber bitte mit der richtigen Begründung.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ich hoffe, daß macht er dann nur für Werte und nicht auch für Zeiger. Das wäre dann auch ein Grund, einen Bug zu melden.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

Kriz postete
Ich hoffe, daß macht er dann nur für Werte und nicht auch für Zeiger. Das wäre dann auch ein Grund, einen Bug zu melden.

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Beispiel Kopieren von C Strings:
Quellcode:while(*dest++ = *src++); Der Algo braucht zwingend postfixes Zeigerinkrement, sonst funzt das nicht. Würde der Compiler daraus (optimierenderweise) irgendwas in Richtung prefixes Zeigerinkrement wurschteln oder irgendwie von der vom Programmierer gedachten Norm abweichen, wäre das Ergebnis nicht das, was der Programmierer erwartet hätte. Daher ist hier Optimieren nicht sinnvoll, sondern nur für Werteinkremente/-dekremente.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Zitat:

Prefect postete
Das ist Unfug, aus zwei Gründen:

1. Jeder Compiler optimiert das sowieso, so dass post-increment und pre-increment hier äquivalent sind. Wenn dem nicht so ist, kann man das getrost als Bugreport melden.

Zitat:

2. Selbst wenn der Compiler das nicht optimieren würde, wäre diese Art der Optimierung hier völlig daneben (siehe meine Signatur).

Zitat:

Kriz postete
Beispiel Kopieren von C Strings: (...)

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Jo, wenn man den Wert liest macht es *immer* einen Unterschied, ob man Präfix oder Postfix nutzt, auch bei primitiven Werten, z.b:

Quellcode:int i=0;

int x = i++; // x==0
// bzw
int x = ++i; // x==1


caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Was eine geile Diskussion.
Sich mit Prefect über c/++ zu streiten bringts btw nicht, zuhören ist aber schon sinnvoll.
Über den Sinn von++ im Vergleich ++zu braucht man daher nicht sprechen.

Zu den bitops, wer meint mit so Spielchen würde man irgendwas retten können, hat verloren, der Scheiss ist nur unlesbar und muss zwangsläufig kommentiert werden.
Und, wenn man da mit Performance argumentieren wollte, möchte ich das gerne mal gebenched haben.

Zum Thema lesbarkeit spreche ich auch gegen if( NULL == val ), neuere gcc Versionen sagen bei assignments auch an.

Quellcode:#include <string.h>

int main()
{
    char *a = NULL;
    if( a = NULL )
        return 0;
    return 1;
}
Quellcode:gcc -Wall -o test test.c
test.c: In function ‘main’:
test.c:6: warning: suggest parentheses around assignment used as truth value
Ich erkenne das Argument an, aber da es nicht notwendig ist, und ich NULL == val unlogisch finde, find ich die lösung nicht vertretbar, wo -Wall das doch hervorragend löst.

Indenting hat aber noch keiner was zu gesagt, daher ...
Quellcode:if( foo == bar )
{

}
Die Syntax ist geschenkt, die Logik sollte jedoch hervorgehoben werden.

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.