Szersze pytanie:
Czy słyszałeś kiedyś o narzuceniu takiego standardu? Jeśli tak, jaki był tego powód?
Tak, słyszałem o tym, a używanie w pełni kwalifikowanych nazw obiektów zapobiega kolizjom nazw. Choć rzadko, kiedy się zdarzają, mogą być wyjątkowo trudni do rozgryzienia.
Przykład:
Tego rodzaju scenariusz jest prawdopodobnie lepiej wyjaśniony na przykładzie.
Powiedzmy, że mamy dwa Lists<T>należące do dwóch oddzielnych projektów.
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
Kiedy używamy w pełni kwalifikowanej nazwy obiektu, jasne jest, który z nich List<T>jest używany. Ta jasność oczywiście odbywa się kosztem gadatliwości.
I możesz się kłócić: „Zaczekaj! Nikt nigdy nie użyłby dwóch takich list!” W tym miejscu przedstawię scenariusz konserwacji.
Masz napisany moduł Foodla swojej korporacji, który korzysta z zatwierdzonej, zoptymalizowanej korporacji List<T>.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
Później nowy programista postanawia przedłużyć pracę, którą wykonałeś. Nie znając standardów firmy, aktualizują usingblok:
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
I możesz szybko zobaczyć, jak sprawy się psują.
Trywialne powinno być stwierdzenie, że możesz mieć dwie własnościowe klasy o tej samej nazwie, ale w różnych przestrzeniach nazw w ramach tego samego projektu. Więc nie chodzi tylko o kolizję z klasami dostarczonymi w ramach .NET Framework.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
Rzeczywistość:
czy jest to prawdopodobne w większości projektów? Nie, nie bardzo. Ale gdy pracujesz nad dużym projektem z dużą ilością danych wejściowych, starasz się zminimalizować ryzyko wybuchu rzeczy.
Duże projekty z wieloma składającymi się zespołami to szczególny rodzaj bestii w świecie aplikacji. Reguły, które wydają się nieuzasadnione w przypadku innych projektów, stają się bardziej odpowiednie ze względu na strumienie danych wejściowych do projektu i prawdopodobieństwo, że osoby wnoszące wkład nie przeczytały wytycznych projektu.
Może się to również zdarzyć, gdy dwa duże projekty zostaną połączone. Jeśli oba projekty miały podobnie nazwane klasy, zobaczysz kolizje, gdy zaczniesz odwoływać się z jednego projektu do drugiego. Projekty mogą być zbyt duże, aby można je było refaktoryzować, lub zarząd nie zatwierdzi wydatków na sfinansowanie czasu poświęconego na refaktoryzację.
Alternatywy:
Chociaż nie pytałeś, warto zauważyć, że nie jest to świetne rozwiązanie problemu. Nie jest dobrym pomysłem tworzenie klas, które zderzą się bez deklaracji przestrzeni nazw.
List<T>, w szczególności należy je traktować jako słowo zastrzeżone i nie należy używać ich jako nazw klas.
Podobnie poszczególne przestrzenie nazw w projekcie powinny dążyć do uzyskania unikalnych nazw klas. Konieczność przypomnienia sobie, z jaką przestrzenią nazw Foo()pracujesz, to narzut umysłowy, którego najlepiej unikać. Powiedział inny sposób: posiadanie MyCorp.Bar.Foo()i MyCorp.Baz.Foo()zamiar potknąć programistów i najlepiej ich unikać.
Jeśli nic więcej, możesz użyć częściowych przestrzeni nazw, aby rozwiązać niejednoznaczność. Na przykład, jeśli absolutnie nie możesz zmienić nazwy żadnej z Foo()klas, możesz użyć ich częściowych przestrzeni nazw:
Bar.Foo()
Baz.Foo()
Konkretne powody twojego obecnego projektu:
Zaktualizowałeś swoje pytanie, podając konkretne powody, dla których otrzymałeś projekt zgodnie z tym standardem. Rzućmy na nie okiem i naprawdę zanurkujmy szlakiem króliczka.
Najechanie kursorem myszy nad nazwę jest kłopotliwe, aby uzyskać w pełni kwalifikowany typ. Lepiej zawsze mieć zawsze w pełni kwalifikowany typ.
"Nieporęczny?" Yyy ... nie. Być może denerwujące. Przeniesienie kilku uncji plastiku w celu przesunięcia wskaźnika na ekranie nie jest uciążliwe . Ale dygresję.
Ten tok rozumowania wydaje się bardziej ukrywaniem niż czymkolwiek innym. Domyślam się, że klasy w aplikacji są słabo nazwane i musisz polegać na przestrzeni nazw, aby uzyskać odpowiednią ilość informacji semantycznych otaczających nazwę klasy.
Nie jest to uzasadnione uzasadnienie dla w pełni kwalifikowanych nazw klas, być może jest to uzasadnione uzasadnienie dla używania częściowo kwalifikowanych nazw klas.
Fragmenty kodu wysyłane pocztą e-mail nie mają w pełni kwalifikowanej nazwy, dlatego mogą być trudne do zrozumienia.
Ta (kontynuowana?) Linia rozumowania potwierdza moje podejrzenie, że klasy są obecnie źle nazwane. Ponownie, posiadanie złych nazw klas nie jest dobrym uzasadnieniem dla wymagania od wszystkiego, aby używać w pełni kwalifikowanej nazwy klasy. Jeśli nazwa klasy jest trudna do zrozumienia, istnieje znacznie więcej błędów niż to, co mogą naprawić w pełni kwalifikowane nazwy klas.
Podczas przeglądania lub edycji kodu poza Visual Studio (na przykład Notepad ++) niemożliwe jest uzyskanie w pełni kwalifikowanej nazwy typu.
Ze wszystkich powodów ten prawie zmusił mnie do wyplucia drinka. Ale znowu dygresję.
Zastanawiam się, dlaczego zespół często edytuje lub wyświetla kod poza Visual Studio? A teraz patrzymy na uzasadnienie, które całkiem dobrze jest prostopadłe do tego, co mają zapewnić przestrzenie nazw. Jest to argument oparty na oprzyrządowaniu, podczas gdy przestrzenie nazw służą do zapewnienia struktury organizacyjnej kodu.
Wygląda na to, że projekt własny cierpi z powodu złych konwencji nazewnictwa wraz z programistami, którzy nie wykorzystują tego, co może zapewnić narzędzie. Zamiast rozwiązać te rzeczywiste problemy, próbują uderzyć bandażem na jeden z symptomów i wymagają w pełni kwalifikowanych nazw klas. Myślę, że można bezpiecznie zakwalifikować to jako błędne podejście.
Biorąc pod uwagę, że istnieją źle nazwane klasy i przy założeniu, że nie można dokonać refaktoryzacji, poprawną odpowiedzią jest pełne wykorzystanie możliwości Visual Studio IDE. Być może rozważ dodanie wtyczki takiej jak pakiet VS PowerTools. Następnie, kiedy patrzę AtrociouslyNamedClass(), mogę kliknąć nazwę klasy, nacisnąć F12 i przejść bezpośrednio do definicji klasy, aby lepiej zrozumieć, co ona próbuje zrobić. Podobnie, mogę kliknąć Shift-F12, aby znaleźć wszystkie miejsca w kodzie, które obecnie cierpią z powodu konieczności użycia AtrociouslyNamedClass().
Jeśli chodzi o zewnętrzne obawy związane z oprzyrządowaniem - najlepiej po prostu to zatrzymać. Nie wysyłaj fragmentów wiadomości e-mail w tę iz powrotem, jeśli nie są od razu jasne, do czego się odnoszą. Nie używaj innych narzędzi poza Visual Studio, ponieważ narzędzia te nie mają inteligencji otaczającej kod, którego potrzebuje Twój zespół. Notepad ++ to niesamowite narzędzie, ale nie jest przeznaczone do tego zadania.
Zgadzam się zatem z twoją oceną dotyczącą trzech konkretnych uzasadnień, które zostały przedstawione. To powiedziawszy, myślę, że powiedziano ci: „Mamy podstawowe problemy w tym projekcie, które nie mogą / nie mogą rozwiązać i w ten sposób je„ naprawiliśmy ”. I to oczywiście przemawia do głębszych problemów w zespole, które mogą służyć za czerwone flagi.