Anzeige:
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 17

Thema: Guten Stil aneignen

  1. #1
    Registrierter Benutzer Avatar von Berufspenner
    Registriert seit
    30.03.2002
    Ort
    Hamburg
    Beiträge
    567

    Guten Stil aneignen

    Hi@all

    Ich programmiere ein wenig in C++ und bin auch fleisig am lernen. Mir ist aber als Anfänger auch der Stil recht wichtig um produktiven Code ohne Umwege zu schreiben. Könnt ihr mir ein paar Tipps geben worauf man allgemein achten sollte oder auch einen Link nennen?

    Cu
    André
    C und C++

  2. #2
    Registrierter Benutzer Avatar von Berufspenner
    Registriert seit
    30.03.2002
    Ort
    Hamburg
    Beiträge
    567
    Hi@all

    Hat den keiner einen Tip?

    Cu
    André
    C und C++

  3. #3
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Guter Stil im Sinne von Codingstyle oder Entwurfsstil?

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  4. #4
    Registrierter Benutzer Avatar von Berufspenner
    Registriert seit
    30.03.2002
    Ort
    Hamburg
    Beiträge
    567
    Original geschrieben von anda_skoa
    Guter Stil im Sinne von Codingstyle oder Entwurfsstil?

    Ciao,
    _
    Ach, wenn du so fragst würde mich schon beides interessieren

    Cu
    André
    C und C++

  5. #5
    Registrierter Benutzer
    Registriert seit
    24.02.2003
    Beiträge
    43
    coding style am besten mit: indent, das ist zum blei in anjuta drin.
    kann man dann per knopfdruck den quellcode formatieren.

    laut linus: Kernighan & Ritchie style, ein tab hat 8 leerzeichen

    gruss pulp

  6. #6
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Beim Codingstyle ist es das wichtigste, dass man ihn einhält

    Wenn man nicht gerade selbst ein Projekt startet, ist der Codingstyle meist ohnehin vorgegeben.

    Gute Stile haben zB eine leichte Unterscheidung zwischen Variablen der Klasse und lokalen Variablen.

    Methoden sollte so heißen, wie das, was sie tun.

    Dokumentation der Methoden und Variablen kommt üblicherweise in den Header.
    Zum Beispiel im Doxygen Stil.

    Dokumentation im Source nur dort, wo es nötig erscheint, also die Vorgänge oder Gründe nicht aus dem Code selbst ersichtlich sind.
    Dabei ist viel Kommentar oft ein Zeichen für schlechtes Design oder überkomplizierten Code.

    Includes in Headern vermeiden, wenn es auch eine Forwarddeclaration tut.

    Design ist praktisch Übungssache.
    Als Grundlagen sind Designpatterns angebracht.

    Allerdings darf man da nicht zuviel wollen, das kommt nach und nach.
    Auch wenn es frustrieren ist, dass man eine Zeit lang kein echt brauchbares Design hinbekommt.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  7. #7
    Registrierter Benutzer Avatar von bischi
    Registriert seit
    10.04.2003
    Beiträge
    4.828
    @pulp: ein Tab immer 2 Leerschläge (sonst wird das ganze viel zu breit!)

    @Berufspenner: Schau dir einfach mal beispielcodes an (open Source,...), dabei lernst du am meisten und du siehst auch gleich, wie andere das Problem handhaben.

    MfG Bischi

    "There is an art, it says, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss it" The hitchhiker's guide to the galaxy by Douglas Adams

    --> l2picfaq.pdf <-- www.n.ethz.ch/~dominikb/index.html LaTeX-Tutorial, LaTeX-Links, Java-Links,...

  8. #8
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Original geschrieben von pulp
    laut linus: Kernighan & Ritchie style, ein tab hat 8 leerzeichen
    8 sind imho a bisserl viel

    3 oder 4 ist wohl schon eher vernünftig

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  9. #9
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Original geschrieben von bischi
    @Berufspenner: Schau dir einfach mal beispielcodes an (open Source,...), dabei lernst du am meisten und du siehst auch gleich, wie andere das Problem handhaben.
    naja, die sind schnell so kompliziert, dass du oft nicht weisst, was weshalb wie läuft...

    ausserdem ist das Design auch bei OSS-Programmen nicht immer _der_ Hammer

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  10. #10
    Registrierter Benutzer Avatar von bischi
    Registriert seit
    10.04.2003
    Beiträge
    4.828
    Ich meinte auch nur für die Quellcodegestaltung und nicht etwa für das Design!

    MfG Bischi

    "There is an art, it says, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss it" The hitchhiker's guide to the galaxy by Douglas Adams

    --> l2picfaq.pdf <-- www.n.ethz.ch/~dominikb/index.html LaTeX-Tutorial, LaTeX-Links, Java-Links,...

  11. #11
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    aber das Problem ist ja das Design, die Quellcodegestaltung läst dich nicht viel falsch machen, sofern du es immer gleich machst

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  12. #12
    Registrierter Benutzer Avatar von Berufspenner
    Registriert seit
    30.03.2002
    Ort
    Hamburg
    Beiträge
    567
    Original geschrieben von bischi
    Ich meinte auch nur für die Quellcodegestaltung und nicht etwa für das Design!

    MfG Bischi
    Also was die Codegestalltung angeht, hab ich eigentlich keine Probleme. Whitespace wird bei mir ordentlich genutzt, siehe hier: http://www.coderbude.de/go/forum/viewtopic.php?t=3 Es geht mir darum, Code zu erstellen der so klein wie möglich, verständlich (nachvollziehbar) und produktiv wie ist. Man kann ja um ein Problem zu lösen, zich viele Zeilen schreiben oder auch einfach in 2-3 Zeilen zusammen fassen und trotzdem ist das Ergebnis das selbe. Sicherlich hat das auch immer was mit der Programmiererfahrung zu tun. Aber vieleicht gibt es da ja trotzdem Sachen, auf die man auf jeden Fall achten sollte.

    Cu
    André
    C und C++

  13. #13
    Registrierter Benutzer Avatar von Berufspenner
    Registriert seit
    30.03.2002
    Ort
    Hamburg
    Beiträge
    567
    Original geschrieben von peschmae
    aber das Problem ist ja das Design, die Quellcodegestaltung läst dich nicht viel falsch machen, sofern du es immer gleich machst

    MfG Peschmä
    Genau das ist es was ich meine.

    Cu
    André
    C und C++

  14. #14
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    tja, so einfach ist das leider nicht

    deshalb passiert es mir meistens, dass ich Projekte nach einer gewissen Zeit aufgebe, da ich das Design scheisse und auch den gesamten Code Überholungsbedürftig finde

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  15. #15
    Registrierter Benutzer
    Registriert seit
    24.02.2003
    Beiträge
    43
    @bischi:

    sag das linus torwalds

    btw wenn man sich mal dran gewöhnt hat es ist sehr übersichtlich

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •