Module - Konventionen bei Prozedurenamen

[STARGÅTE]

Es mag ja durchaus sein, das man dem Drang nicht widerstehen kann, eine bereits existierende Prozedur durch eine eigene Implementierung ersetzen möchte.

In diesem Fall will ich ja gar nicht die Abs() Funktion von PureBasic ersetzen, sondern nur ermöglichen, dass es in einem Modul auch eine Funktion Abs() geben kann, die nun mal genauso heißt, weil sie eigentlich das gleiche Machen soll, nur für einen anderen Zahlentyp.
Klar ich könnte sie auch AbsComplex oder AbsC oder C_Abs nennen, am "schönsten" aussehen und am lesbarsten finde ich aber C::Abs() oder gerne auch Cmplx::Abs()

[TroaX]

Klar ich könnte sie auch AbsComplex oder AbsC oder C_Abs nennen, am "schönsten" aussehen und am lesbarsten finde ich aber C::Abs() oder gerne auch Cmplx::Abs()

Kann das sein, das wir beide ...
1. ... unterschiedliche Auffassungen dazu haben, wie man Module einsetzen sollte?
2. ... unterschiedliche Auffassungen dazu haben, wie man generell mit der Benennung von Modulen und ggf. Prozeduren umgehen sollte?
3. ... unterschiedliche Auffassungen dazu haben, was gut lesbar ist und was nicht?

Ich werde das blöde Gefühlt nicht los, das für dich "lesbar" bedeutet, so wenig Zeichen wie möglich zu verwenden. Du sparst sogar 2 Buchstaben bei den Begriff "Complex" noch ein. Ich denke es ist für dich lesbarer, weil du natürlich wissen musst, was dahinter steckt und für dich in der Kürze die Würze liegt. Ich sehe das aber definitiv mal komplett ganz und gar anders.

[NicTheQuick]

Ich würde das Module auch eher "Complex" nennen, aber ich würde definitiv bei "Abs()" bleiben wollen.

[Benubi]

Ich bin da noch nicht ganz festgelegt und probiere noch rum. Allgemein kann es auch schon schwer sein den richtigen Modulnamen zu wählen; auch hier ist es von Vorteil wenn dieser kurz gehalten wird (selbstverständlich).

Ich benutze meistens UnuseModule nach dem UseModule.

Code: Alles auswählen

Module B
UseModule A
(...)
(...)
UnUseModule A
EndModule ; 


; ---- main scope
Procedure MyProc()
 UseModule B
 ; ....
   ProcedureReturn 
 UnuseModule B
EndProcedure

Bei Konstruktoren und Desktruktoren habe ich zu Anfangs einfach New() und Free() als Namen genutzt, aber das verursacht Konflikte und oft habe ich "überladene" (mehrere hehe) Konstruktoren. Daher gebe ich lieber den Objektnamen mit an.

Code: Alles auswählen

; Declares...
Module Object
Procedure CreateObject()
EndProcedure
Procedure FreeObject() 
EndProcedure
EndModule 

Wenn dann aber ein Interface für das "Objekt" bereitgestellt wird dann kürze ich wieder die Namen so sehr es geht und Sinn macht

Code: Alles auswählen

Interface Object
  Create()
  Free()

Manchmal muss ich dennoch Präfixe nutzen, weil es ohnehin Kollisionen mit dem PB Namensraum gibt wie z.B. Tree_AddElement() ResourceManager_LoadImage() oder XYZ_CreateNode() aber wenn man seine Strukturen/Objekte einfach umbenennt z.B. "Element" zu "Item", dann hat kann man es auch meist easy umgehen.

[DarkDragon]

Klar ich könnte sie auch AbsComplex oder AbsC oder C_Abs nennen, am "schönsten" aussehen und am lesbarsten finde ich aber C::Abs() oder gerne auch Cmplx::Abs()

Kann das sein, das wir beide ...
1. ... unterschiedliche Auffassungen dazu haben, wie man Module einsetzen sollte?
2. ... unterschiedliche Auffassungen dazu haben, wie man generell mit der Benennung von Modulen und ggf. Prozeduren umgehen sollte?
3. ... unterschiedliche Auffassungen dazu haben, was gut lesbar ist und was nicht?

Ich werde das blöde Gefühlt nicht los, das für dich "lesbar" bedeutet, so wenig Zeichen wie möglich zu verwenden. Du sparst sogar 2 Buchstaben bei den Begriff "Complex" noch ein. Ich denke es ist für dich lesbarer, weil du natürlich wissen musst, was dahinter steckt und für dich in der Kürze die Würze liegt. Ich sehe das aber definitiv mal komplett ganz und gar anders.

Das kommt immer darauf an wie häufig man etwas verwendet. Unter C++ würde ich auch nicht "standard::" ausschreiben wollen, da schreibt man lieber die, ohne Kontextwissen vielleicht verstörende Abkürzung "std::". Wenn man jedoch abs abändert ist das ein noch viel größerer Stilbruch, denn die Funktion heißt in tausenden von Frameworks nunmal abs.

[STARGÅTE]

Kann das sein, das wir beide ...
1. ... unterschiedliche Auffassungen dazu haben, wie man Module einsetzen sollte?
2. ... unterschiedliche Auffassungen dazu haben, wie man generell mit der Benennung von Modulen und ggf. Prozeduren umgehen sollte?
3. ... unterschiedliche Auffassungen dazu haben, was gut lesbar ist und was nicht?

Kann ich nicht beantworten, aber ich kann dich ja mal direkt Fragen, wie du eine Funktion (und das Modul) nennen würdest, die den Betrag einer Komplexen Zahl berechnen soll.

Ich werde das blöde Gefühlt nicht los, das für dich "lesbar" bedeutet, so wenig Zeichen wie möglich zu verwenden. Du sparst sogar 2 Buchstaben bei den Begriff "Complex" noch ein. Ich denke es ist für dich lesbarer, weil du natürlich wissen musst, was dahinter steckt und für dich in der Kürze die Würze liegt. Ich sehe das aber definitiv mal komplett ganz und gar anders.

Ja gut, das mit Cmplx war vielleicht etwas überspitzt. Eigentlich tendiere ich auch ehr zu längeren Variable- oder Funktionsnamen, anstatt einem "i" auch gerne mal "Index" oder "Position" zu schreiben.
Gerade bei Mathe-Modulen schreibe ich (und vielleicht auch andere) Formeln aber gerne als Einzeiler.
Wenn ich also z.B. die Wurzel einer komplexen Zahl über e^(0.5*log(z)) berechnen will, würde der Code in meiner "Wunsch"-Welt z.B. so aussehen:

Code: Alles auswählen

C::Exp(C::Scale(C::Log(*Z), 0.5))

Das würde sich aber schnell aufblähen, wenn ich die PB-Kollisionen berücksichtige und das Modul ausschreibe:

Code: Alles auswählen

C::C_Exp(C::C_Scale(C::C_Log(_Z), 0.5))
C::Exponential(C::Scale(C::Logarithm(*Z), 0.5))
Complex::Exponential(Complex::Scale(Complex::Logarithm(*Z), 0.5))

Natürlich ist der letzte Code lesbarer im Sinne des Verständnisses für einen Dritten.
Der erste Code ist in meinen Augen aber auf mathematischer Ebene schneller erfassbar, weil Mathematiker nun mal auf kurze Funktionsnamen getrimmt sind.