Nazewnictwo klas i wasze przyzwyczajenia.

0

Otóż chciałem zapytać was, czy macie jakieś takie "przyzwyczajenia" w pisaniu programów, tudzież podobieństwo w nich? Przykładowo mogę powiedzieć że moje przyzwyczajenie to pisanie

const
  AppTitle = 'tytuł aplikacji';

co by to nie było. W 95% programów deklaruję nowy typ i na jego podstawie talibcę

type
  TArrayType = (atMain, atBackground, atButton);

var
  Pictures : array [TArrayType] of TBitmap;

Właśnie o takie przyzwyczajenia mi chodzi, podzielicie się swoimi?

Drugie pytanie to czy przy wymyślaniu nazw typów i klas sugerujecie się czymś? Nazywacie je po polsku czy po angielsku? Ostatnio miałem dylemat bo tworzyłem grę z cieniem zaimplementowanej fizyki i chciałem dodać jakieś obiekty typu puszka, jabłko etc. "Obiekt" to po angielsku "Obiect", ale TObject jest już zadeklarowany, myślałem jakieś pół godziny bo przecież nie nazwę klasy TPrzedmiot albo TThing, więc w końcu nazwałem TObiect2, ale średnio mi się podoba.

0

Cóż,nie stosuję żadnych przedrostków,nazwa klasy z dużej litery,obiekty z małej,nazwy staram się nadawać opisowe.Przykład:

class LOGGER_EXPORT LoggerObject : public QObject
{
friend class LoggerManager;

	Q_DISABLE_COPY(LoggerObject)

	QList<LogData> logs;//contains log messages.Filled by LoggerManager::printLog()
	
	bool topWindow;
	unsigned int allowedTypes;//bitfield of BLBLogger::LogType values
	unsigned int maxLevel;//means that only logs <0,maxLevel> will be printed
	QString id;//identifier of logger in LoggerManager::loggers map
	LogMode mode;//determines where the logs shoud be put in	
	QFile logFile;
	int maxLogFiles;//used for rotation.Default 10
	unsigned int maxLogFileSize;//if the log exceedes this size in kB it will be rotated.Default 0 means no rotation
	LogRotationType rotationType;
	int rotationHour,rotationMinute;
	QDateTime rotationTime;
	int timerID;
	QPointer<LogWindow> logWindow;	
	static bool isConsoleApplication;//holds result of checking if there is QApplication or QCoreApplication

	void timerEvent(QTimerEvent *e);
	void checkIfRotationIsNeeded(void);
	void performLogRotation(void);
	LoggerObject(const QString &id,QObject *parent);
	~LoggerObject(void);

public:
	QString identifier(void);
	
	bool setLogMode(LogMode mode,QString &errorMessage);
	LogMode logMode(void);

	void allowLogTypes(unsigned int types);
	unsigned int allowedLogTypes(void);
	void setMaximumLogLevel(unsigned int level);
	unsigned int maximumLogLevel(void);

	bool setLogFile(const QString &filename);
	QFileInfo logFileInfo(void);

	bool isLogWindowOnTop(void);
	void setLogWindowOnTop(bool top);

	int maximumArchievedFiles(void);
	void setMaximumArchievedFiles(int max);
	unsigned int maximumLogFileSize(void);
	void setMaximumLogFileSize(unsigned int kB);
	void logFileRotationTime(BLBLogger::LogRotationType &outType,int &outHours,int &outMinutes);
	void setLogFileRotationTime(BLBLogger::LogRotationType type,int hours,int minutes,const QDateTime &startAt);
	void cancelLogFileRotation(void);

	void printLog(const QString &text,int line,const QString &file,int level,int type,bool isInternalCall=false);
};
0

Zależy od języka. Nazwy też staram się dawać opisowe, bez przedrostków, bardzo podobnie jak MasterBLB, ale np z małą różnicą: zamiast bleBleIsNeeded dałbym bleBleNeeded :)

W C używam typedefów do definiowania struktur, np:

typedef struct {
int32_t pole1;
int32_t pole2;
} struktura_t;
struktura_t tablica[5];

Ponadto walę jak najwięcej constów, to daje dobry obraz tego czy funkcja modyfikuje obiekt, czy na jego podstawie tylko coś oblicza i zwraca. Asserty też dodaję w miarę możliwości. No i jak widać na przykładzie, stosuję np int32_t zamiast int, bo w różnych kompilatorach int może mieć różną wielkość, a int32_t jest jednoznaczne. A więc stdbool.h i stdint.h mymi przyjacielami są :p

Te prefiksy czy sufiksy nazw to są raczej podyktowane wpisaniem się w konwencję języka. Pisząc w Delphi pewnie też bym pisał TCośtam (ale nie piszę w Delphi), bo tam wszystko jest tej postaci. Podobnie w C typy są postaci cośtam_t, w Javie czy C# nie ma ani prefików ani sufiksów.

0

Ja właściwie podobnie jak MaserBl tyle, że klamry stawiam tak:
class LOGGER_EXPORT LoggerObject : public QObject{
****
}
Mam również nawyk do constów jak Wibowit.
Chyba, że piszę w C#, wtedy nie zmieniam tego co IDE poprawi:)

0

Zazwyczaj trzymam się konwencji danego języka. Jak konkretne IDE formatuje automatycznie kod, też na siłę nie poprawiam.
const w C i C++ jest istotne, w C# istnieje w śladowej postaci. Nie wszystkie „dobre praktyki” daje się przenieść wszędzie.

Mam też często w głębokim poważaniu pewne arbitralne a często szkodliwe zasady (np. jednego returna, czy unikania pól publicznych).
Funkcje nie powinny być za długie o złożonych, wielokrotnie zagnieżdzonych pętlach. Dzisiaj w pociągu napisałem funkcję (w C#) na 1000 linii kodu — po czym się opamiętałem i rozbiłem na mniejsze ;-)

Nie wkuwam „wzorców projektowych”, bo połowa z nich jest oczywistością (Napisał trzy linijki kodu i nazwał linijki kodu Wzorcem. I widział, że były dobre.) a druga połowa jest tylko próbą omijania ograniczeń języka, zwykle Javy.

Pisz tak, jak piszą twórcy danego języka: w Delphi wzorem jest kod Borlanda/Abrakadabra. w C# — Microsoftu. W Javie — Suna/Oracle'a.
A w C++ sam diabeł nie pomoże.

0

Wszystko jedno jaka konwencja byle by ją spójnie stosować. Wyjątkowo wkurwiają mnie ludzie, którzy przychodzą do projektu i zaczynają klepać w swojej wyuczonej konwencji nie patrząc na kod bazowy. Konwencje ustala autor projektu a jak ktoś zaczyna stosować inne konwencje to z projektu robi się zlepek gówna.

0

Staram się trzymać konwencji języka odnośnie np. używania notacjiWielbłądziej (Java) czy też WersjiZWielkąPierwsząLiterą (C# -- ogólnie wiele API MS).

Nigdy nie używam polskich nazw. Staram się ograniczać liczbę języków w jednym pliku. Gdy robię interfejs aplikcji intranetowej, JavaScript ląduje w plikach .js, style CSS w .css, a znaczniki HTML w .html. Unikam zagnieżdżania jednego w drugim i prawie zawsze wychodzi.

Zasada ograniczania liczby języków dotyczy też języków naturalnych. Dlatego nigdy nie pomieszałbym polskiego z angielskim, szczególnie na tym samym poziomie abstrakcji. Komunikaty po polsku byłyby jeszcze OK, ale identyfikatory raz po polsku, a raz po angielsku -- mowy nie ma (jedynie czasem, "na kartce" gdy chcę kogoś nauczyć, używam polskich identyfikatorów).

Staram się, by jedno pojęcie było reprezentowane w aplikacji przez jedno słowo lub frazę. Np. wszystkie metody wytwórcze mają przedrostek create (a nie że jedne createXxx, drugie buildXxx, trzecie jeszcze coś innego). Wszystkie zmienne oznaczające długość mają przyrostek Count (a nie Size lub Length).

Staram się, by nazwy nie różniły się jedną literą. Np. gdy mam dwie funkcje: jedna, która usuwa jeden obiekt i druga, która usuwa kilka obiektów, raczej nie dodaję tylko s na końcu (remove(listener) / removeListeners(someListeners)), tylko jeszcze dodaję słowo All (removeListener(listener)/removeAllListeners(someListeners)).

Niekiedy czerpię wprost ze wzorców projektowych, tj. mogę dodać przyrostek Decorator lub Builder w zależności od potrzeb.

W JavaScripcie czasem gubimy kontekst wykonania, tj. wartość this. Wtedy, zgodnie z popularną konwencją, zapisuję wartość this w zmiennej o nazwie that. Podobnie, np. obiekty biblioteki jQuery zawsze zapisuję w zmiennych zaczynających się od znaku $.

Do nazw przywiązuję dużą wagę. Często refaktoryzuję. Kłuje mnie coś w żołądku, gdy widzę nieudaną nazwę. Czasem zmieniam ją na długą i opisową, ale wtedy się zastanawiam, czy może zmienna nie jest zbyt skomplikowana, może klasa ma za dużo odpowiedzialności itp.

W Twoim przykładzie na pewno nie użyłbym nazwy Object2. Może adekwatne byłoby np. PhysicalObject?

0

@Wibowit:
Może i nieintuicyjne. BTW siedzisz dużo w JavaScripcie, czy nie? Mi się that nie podobało na początku przygody z JS-em. Potem się przyzwyczaiłem.

Problem utraty kontekstu jest w JavaScripcie powszechnie spotykany (to jeden z błędów projektowych języka), więc w społeczności przyjęła się standardowa nazwa dla zmiennej spamiętującej wartość this. Nazwę spopularyzował ją Douglas "Staruszek" Crockford, autor znanej książki "JavaScript. Mocne strony.". Nazwą tą była właśnie that.

Ja wcześniej miałem konwencję, że nazwy "pól prywatnych klasy" (to są duże cudzysłowy) zaczynałem od znaku podkreślenia. Mogłem więc przechowywać this w zmiennej _this. Nie lubię przejawów notacji węgierskiej i próbuję się przestawić na nieużywanie znaków podkreślenia, ale w JavaScripcie nie wolno deklarować zmiennej o nazwie this -- jest to słowo zastrzeżone. Więc musiałem użyć czegoś innego i wybór padł na to that.

Niektórzy używają jeszcze self. Byłaby to całkiem fajna nazwa, szczególnie że np. w Pythonie występuje właśnie self zamiast (?) this. Ale w przeglądarkowym JavaScripcie jest już zadeklarowana zmienna self -- wskazuje na bieżące okno. To nie jest część języka, tylko środowiska wykonania (np. w NodeJS nie ma zmiennej self), więc niby można bez problemu nadpisać tę zmienną i zgarnąć nazwę do własnych zastosowań. Niemniej jednak mogłoby to być mylące.

@TomRiddle:
Inne, krótkie propozycje to np. Entity (Physical- lub nie). IIRC widywałem to w kodzie silników gier.


Disclaimer: Odpowiadam w poście na komentarze do poprzedniego posta -- dziwnie by było merge'ować te posty, a w komentarzu mi się nie zmieści.

0

W Pythonie self jest konwencja, niczym wiecej - mozesz uzywac czegokolwiek chcesz, ale to bedzie 'frowned upon' ;d Self jest jeszcze uzywane w kategoriach Groovy - klasy ktore rozszerzaja juz istniejace klasy, posiadajace metody statyczne, ktorych pierwszym parametrem jest obiekt klasy rozszerzanen - i on wlasnie czesto jest self, jednak nie jest to tak mocno zakorzenione (jeszcze?) jak w Pythonie.

Aby nie zbaczac zbytnio - osobiscie stosuje lekko zmodyfikowane konwencje Suna w Javie, konwencje Ms w .NET, Pythona w Pythonie itd. itp. Czesto konwencje jedneog jezyka sa calkowicie zabronione lub uznawane za nieczytelne w innym, np. Pythoniczny kod uzywa takich_nazw_metod, co w Javie wyglada po prostu dziko.
Nie podchodze do konwencji religijnie - jesli w module pisanym przez kogos innego sa inne konwencje, staram sie ich uzywac (chyba ze sie zapomne) aby kod wygladal nie jak 'zlepek roznych gowien', lecz jednokolorowe gowno - mimo wszystko jest spojniej i latwiej sie polapac czytajac.

1 użytkowników online, w tym zalogowanych: 0, gości: 1