Zamknięte. To pytanie jest
nie na temat . Obecnie nie przyjmuje odpowiedzi.
Komentarze
Odpowiedz
Jeśli dalej napiszę więcej kodu, to będzie czas, kiedy będzie mi trudno go uporządkować.
Oto twój problem: zadbaj o właściwą organizację, a styl powinien płynąć łatwiej.
Nie czekaj na uporządkowanie kodu: utrzymuj porządek w kodzie na bieżąco. Chociaż język nie robi tego za Ciebie, kod powinien być nadal zorganizowany w moduły o niskim sprzężeniu i dużej spójności.
Te moduły w naturalny sposób zapewniają wtedy przestrzeń nazw. Skróć nazwę modułu (jeśli jest długa) i dodaj przedrostek nazwy funkcji do ich modułu, aby uniknąć kolizji.
Na poziomie indywidualnych identyfikatorów są one mniej więcej w kolejności rosnącej subiektywności:
- wybierz konwencję i trzymaj się jej
- np.
function_like_this(struct TypeLikeThis variable) jest powszechne
-
zdecydowanie unikaj notacji węgierskiej (przepraszam JNL)
-
chyba że „chcesz używać jej zgodnie z pierwotnym przeznaczeniem, co oznacza raczej notację aplikacji Simonyi niż okropna wersja systemu
Dlaczego? Mógłbym napisać esej na ten temat, ale zamiast tego zasugeruję, abyś przeczytał ten artykuł autorstwa Joela Spolskyego, a potem poszukaj więcej, jeśli jesteś zainteresowany. Na dole znajduje się link do oryginalnej pracy Simonyi.
-
Unikaj czcionek wskaźnikowych, chyba że są one naprawdę nieprzezroczystymi typami plików cookie – pomieszać rzeczy
struct Type *ok; typedef struct Type *TypePtr; TypePtr yuck;
Co mam na myśli przez nieprzezroczysty typ pliku cookie ? Mam na myśli coś używanego wewnątrz modułu (lub biblioteki lub cokolwiek), który musi zostać przekazany do kodu klienta, ale ten kod klienta nie może „t używać bezpośrednio. Po prostu przekazuje go z powrotem do biblioteki.
Na przykład biblioteka bazy danych może ujawnić interfejs taki jak
/* Lots of buffering, IPC and metadata magic held in here. No, you don"t get to look inside. */ struct DBContextT; /* In fact, you only ever get a pointer, so let"s give it a nice name */ typedef struct DBContexT *DBContext; DBContext db_allocate_context(/*maybe some optional flags?*/); void db_release_context(DBContext); int db_connect(DBContext, const char *connect); int db_disconnect(DBContext); int db_execute(DBContext, const char *sql);
Teraz kontekst jest nieprzezroczysty dla kodu klienta, ponieważ nie można „zajrzeć do środka”. Po prostu przekazujesz go z powrotem do biblioteki. Coś w rodzaju FILE również jest nieprzezroczyste, a deskryptor pliku będącego liczbą całkowitą jest również plikiem cookie , ale nie jest „nieprzezroczysty”.
Uwaga dotycząca projektu
Użyłem wyrażenia niskie sprzężenie i wysoka spójność powyżej bez wyjaśnienia i czuję się z tym trochę źle. Możesz go poszukać i prawdopodobnie znajdziesz dobre wyniki, ale spróbuję krótko się do tego odnieść (znowu mógłbym napisać esej, ale spróbuję tego nie robić).
Biblioteka DB pokazana powyżej pokazuje niskie sprzężenie , ponieważ udostępnia mały interfejs światu zewnętrznemu. Ukrywając szczegóły implementacji (częściowo za pomocą nieprzezroczystej sztuczki cookie), zapobiega uzależnieniu kodu klienta od tych szczegółów.
Wyobraź sobie zamiast nieprzezroczystego pliku cookie, deklarujemy strukturę kontekstu, tak aby jej zawartość była widoczna, i która zawiera deskryptor pliku gniazda dla połączenia TCP z bazą danych. Jeśli później zmienimy implementację na obsługę segmentu pamięci współdzielonej, gdy DB działa na tym samym komputerze, klient musi zostać ponownie skompilowany, a nie tylko ponownie połączony. Co gorsza, klient mógł zacząć używać deskryptora pliku, na przykład wywołać , aby zmienić domyślny rozmiar bufora, a teraz również wymaga zmiany kodu. Wszystkie te szczegóły ils powinny być ukryte wewnątrz naszego modułu, jeśli jest to praktyczne, a to daje niskie sprzężenie między modułami.
Przykład pokazuje również wysoką spójność , ponieważ wszystkie metody w module dotyczą tego samego zadania (dostęp do bazy danych). Oznacza to, że tylko kod, który musi wiedzieć o szczegółach implementacji (czyli zawartość naszego pliku cookie) ma do nich dostęp, co upraszcza debugowanie.
Możesz również zobaczyć, że pojedynczy problem ułatwił wybranie przedrostka w celu zgrupowania tych funkcji.
Powiedzenie, że ten przykład jest dobry, jest łatwe (zwłaszcza, że nie jest nawet nie ukończone), ale nie pomaga od razu. Sztuczka polega na tym, aby podczas pisania i rozszerzania kodu obserwować funkcje, które wykonują podobne rzeczy lub działają na tych samych typach (które mogą być kandydatami dla własnego modułu), a także funkcje, które wykonują wiele oddzielnych rzeczy, które nie są. nie są ze sobą powiązane i mogą być kandydatami do rozstania.
Komentarze
Odpowiedź
Moim zdaniem 90 % problemu nazewnictwa zostanie rozwiązane, jeśli weźmiesz pod uwagę trzy rzeczy: a) nadaj nazwom zmiennych i funkcji tak samo opisowe, jak możliwe, b) być spójne w całym kodzie (tj. jeśli funkcja nosi nazwę addNumbers, druga funkcja powinna mieć nazwę multiplyNumbers a nie numbersMul) i c) staraj się, aby nazwy były krótkie, jeśli to możliwe, ponieważ musimy je wpisać.
Biorąc to pod uwagę, jeśli chcesz przyjrzeć się innym aspektom tego tematu, strona Wikipedii pod adresem Konwencje nazewnictwa zawiera dobrą listę rzeczy, które powinieneś pamiętać. Zawiera również sekcję dotyczącą C i C ++:
W C i C ++ słowa kluczowe i standardowe identyfikatory bibliotek są w większości pisane małymi literami. W standardowej bibliotece C najczęściej używane są skrócone nazwy (np. Isalnum dla funkcji sprawdzającej, czy znak jest alfanumeryczny), podczas gdy biblioteka standardowa C ++ używa podkreślenia jako separatora wyrazów (np. Out_of_range). Identyfikatory reprezentujące makra są, zgodnie z konwencją, zapisywane wyłącznie przy użyciu dużych liter i znaków podkreślenia (jest to związane z konwencją w wielu językach programowania, w której dla stałych stosuje się wielkie litery). Nazwy zawierające podwójny podkreślnik lub rozpoczynające się od podkreślenia i dużej litery są zarezerwowane do implementacji (kompilator, biblioteka standardowa) i nie powinny być używane (np. Zastrzeżone__ lub _Reserved). [5] [6] Jest to pozornie podobne do wykreślania, ale semantyka różni się: podkreślenia są częścią wartości identyfikatora, a nie są znakami cudzysłowu (jak to jest wykreślanie): wartością __foo jest __foo (co jest zastrzeżone), a nie foo (ale w innej przestrzeni nazw).
Komentarze
Odpowiedź
Jedynym twardym ograniczeniem w C jest brak przestrzeni nazw. Dlatego musisz znaleźć sposób na odróżnienie funkcji rename() swojej biblioteki systemu plików od rename() funkcji Twojej biblioteki multimediów . Typowym rozwiązaniem jest prefiks, taki jak: filesystem_rename() i media_rename().
Inna ogólna rada: zostań spójne w ramach projektu lub zespołu. Czytelność zostanie poprawiona.
Komentarze
Odpowiedź
JEŚLI SZUKASZ GLOBALNIE ZAAKCEPTOWANY FORMAT
MISRA / JSF / AUTOSAR obejmuje prawie 100% każdego branżowego standardu nazewnictwa i organizacji kodu C / C ++. Problem w tym, że nie będzie można ich zdobyć za darmo, czyli każdy przewodnik kosztuje trochę pieniędzy. Wiem, że standardowa książka kodowania MISRA 2008 C / C ++ kosztuje prawdopodobnie około 50 USD.
Możesz myśleć o nich jak o Harvard Referencing do bibliografii i dodatkowych lektur, kiedy piszesz czasopismo. Użyłem MISRY i jest to dobry sposób na nazwanie swoich funkcji i zmiennych oraz uporządkowanie ich pod kątem prawidłowego użycia.
JEŚLI SZUKASZ CZEGOŚĆ TYMCZASOWEGO
Wydaje mi się, że odniesienia, które podałeś dla Pythona i Javy, są w porządku. Widziałem ludzi przyjmujących komentowanie, nazywanie i organizowanie kodu w stylu javadoc. Właściwie w moim ostatnim projekcie musiałem napisać kod C ++ w funkcjach / nazwach zmiennych podobnych do Javy. Istnieją dwa powody:
1) Pozornie łatwiej było naśladować.
2) Wymagania dotyczące kodu produkcyjnego nie dotknęły podłoża krytycznych dla bezpieczeństwa standardów systemu oprogramowania.
3) Wcześniejszy kod był (w jakiś sposób) w tym formacie.
4) Doxygen pozwolił na komentowanie sytle Javadoc. W tym momencie używaliśmy doxygen do generowania dokumentacji dla pracowników produkcji.
Wielu programistów będzie temu przeciwnych, ale osobiście uważam, że nie ma nic złego w przyjęciu funkcji / zmiennych w stylu javadoc w języku C / C ++. TAK, OCZYWIŚCIE, praktyki organizowania kontroli przepływu, bezpieczeństwa wątków itp. Należy uwzględnić niezależnie od tego. Jednak nie jestem tutaj wnioskodawcą. Nie wiem też, jak surowe są twoje wymagania dotyczące formatu kodu produkcyjnego. Nie kierując go do obszaru niezwiązanego z tematem, proponuję przejrzeć swoje wymagania, dowiedzieć się, w jakim stopniu jesteś uzależniony od określonej konwencji nazewnictwa i zastosować wymienione rozwiązanie w moich i innych ”odpowiedziach
Mam nadzieję, że to pomogło !?
Komentarze
Odpowiedź
Niewiele ważnych rzeczy, które należy wziąć pod uwagę podczas nazywania, to;
-
Przyjrzyj się typowi actionObject lub ObjectAction. (Obiekt nie dla C. Ale ogólnie, gdy przechodzisz do innych języków obiektowych) To powinno pomóc
-
Reszta byłaby ZGODNA, krótka i na pewno opisowa.
- Ponadto, Jedynym celem każdej zdefiniowanej zmiennej i funkcji, Np .: jeśli służy do tymczasowego przechowywania wartości, nazwij ją jako nTempVal dla int
- Zmienne powinny być rzeczownikami, a metody powinny być czasownikami.
Komentarze
Odpowiedź
Większość odpowiedzi jest dobra, ale chcę powiedzieć kilka rzeczy na temat nazywania konwencje dla bibliotek i dołączonych plików, podobne do używania przestrzeni nazw w innych językach, takich jak C ++ lub Java:
Jeśli tworzysz bibliotekę, znajdź wspólny przedrostek dla eksportowanych symboli, tj. funkcje globalne, typy czcionek i zmienne. Zapobiegnie to konfliktom z innymi bibliotekami i zidentyfikuje funkcje jako pochodzące z Twojej. To trochę aplikacji węgierskich notacji.
Może pójdź jeszcze dalej i pogrupuj wyeksportowane symbole: libcurl używa curl_ * dla symboli globalnych, curl_easy_ *, curl_multi_ * i curl_share_ * dla różnych interfejsów.Dlatego oprócz używania curl_ * dla wszystkich funkcji, dodali kolejny poziom „przestrzeni nazw” dla różnych interfejsów: wywołanie funkcji curl_easy_ * na uchwycie curl_multi_ * wygląda teraz nieprawidłowo. Nazwy funkcji zobacz http://curl.haxx.se/libcurl/c/
Zachowując zasady dotyczące eksportowanych symboli, należy ich używać dla funkcji statycznych w #include pliki ed: spróbuj znaleźć wspólny przedrostek dla tych funkcji. Może masz statyczne funkcje narzędziowe w pliku o nazwie „my_string”? Poprzedź wszystkie te funkcje my_string_ *.
Komentarze