2015-01-07 11 views
5

Może to, czego szukam, nie istnieje, ale słyszałem plotki, że w TFS można ustawić jakiś sposób automatycznego formatowania/Stylizacji kodu źródłowego na check-inach. Do tej pory w badaniach, które przeprowadziłem, wygląda na to, że "Check in Policy" wysyła powiadomienia tylko wtedy, gdy twoje zgłoszenie jest oflagowane ... Czy jest jakiś sposób, że kod może być automatycznie sformatowany podczas odprawy lub jest to tylko życzenie myślący? Czy możesz podać/link do przykładów.Czy istnieje polityka kontroli TFS, która automatycznie formatuje kod?

+3

Najbardziej wiem o automatycznym formatowaniu z [CodeMaid] (http://www.codemaid.net/), który może oczyścić twój kod po zapisaniu. – gunr2171

+3

Resharper ma funkcję automatycznego formatowania plików po zapisaniu lub sformatowaniu całego rozwiązania za pomocą funkcji czyszczenia kodu. TFS ani Visual Studio ma wbudowaną funkcję do sformatowania kodu podczas odprawy (nie chciałbym tego w wielu projektach). Chcę być mistrzem mojego własnego kodu. – jessehouwing

+0

Zobacz także: http://stackoverflow.com/q/3071953/736079 i https://www.jetbrains.com/resharper/features/code_formatting.html – jessehouwing

Odpowiedz

0

Nie są naprawdę bezpośredniej odpowiedzi, ale mogą pomóc komuś:

Dla wielu językach można włączyć automatyczne formatowanie podczas pisania w Visual Studio (Narzędzia> Opcje> Edytor tekstu>> {} języka formatowania), więc nie powinno być zbyt trudno zachować porządek w kodzie przed odprawą.

Dokument można również sformatować na żądanie za pomocą opcji Edycja> Zaawansowane> Formatuj dokument - dzięki czemu można to zrobić tuż przed sprawdzeniem w (chociaż trzeba będzie ponownie otworzyć wszystkie oczekujące zmiany)

Zasadniczo dość szybko i łatwo można zachować dorsza e schludny (szczególnie z powyższym). Jeśli zbytnio powściągniesz "perfekcyjne" formatowanie, tracisz dużo czasu pracując nad wcięciem i układem, zamiast wykonywać pożyteczną pracę - i będziesz się denerwować przez "zepsute" formatowanie po powrocie do ten sam kod kilka tygodni później, tylko po to, aby odkryć, że to, co uważałeś za doskonałe, wciąż miało pewne usterki, lub że twój osobisty styl kodowania nieznacznie uległ zmianie. Takie zachowanie może nawet prowadzić do bitew stylowych z innymi, gdy próbujesz pracować w zespole, co może być poważnie destrukcyjnym działaniem. Wartość uczenia się jest wtedy, gdy "wystarczająco dobre jest wystarczająco dobre" i nie marnuj energii, starając się osiągnąć doskonałość.

Wreszcie, bardzo łatwo byłoby napisać kod, który znajduje się na zdarzeniu TFS i przetworzyć wszystkie checkiny, aby wymusić styl układu kodowania. Ale znowu, jeśli czujesz, że wysiłek jest potrzebny/uzasadniony, prawdopodobnie powrócisz do perfekcji w swoim układzie tekstu i może odnieść korzyść, skupiając się bardziej na napisaniu dobrego kodu, który można utrzymać, niż na tym, aby wyglądał ładnie. Kompilator nie dba o to, więc dopóki kod jest czytelny dla ciebie i członków twojego zespołu, prawdopodobnie jest wystarczająco dobry.

+5

Doskonałym powodem używania narzędzia do formatowania kodu podczas odprawy jest sytuacja, gdy różni deweloperzy mają inne preferencje dotyczące stylu. Kiedy Dev a. odprawa, kod w repozytorium będzie identyczny z tym, gdy Dev b. odprawy - więc porównania źródeł pokażą tylko rzeczywiste zmiany kodu, a nie zmiany formatowania. Po wyewidencjonowaniu poszczególni twórcy mogą użyć dowolnych narzędzi formatowania, które im odpowiadają, tak aby wyglądały tak, jak powinny. przydaje się to szczególnie w przypadku wojen "kędzierzawych brasów". – Maxxx

+3

Muszę się nie zgodzić. Podczas pracy nad projektem jako jedynym programistą formatowanie nie ma znaczenia i może być łatwe do opanowania. Jednak pracując jako część zespołu, jeśli wielu członków zespołu ma swój własny styl i preferencje redaktora, niespójne formatowanie w projekcie może spowolnić programistów. Posiadanie narzędzia, które automatycznie wymusza uzgodniony styl kodu, jest bardzo przydatne, gdy pracuje jako członek zespołu. Używanie takiego narzędzia nie polega na "zawieszaniu się na" doskonałym "formatowaniu, ale raczej na używaniu komputera do wymuszania pewnych wspólnych konwencji. – Chris

+0

Klucz jest "tak długo, jak kod jest czytelny dla Ciebie i członków Twojego zespołu". Posiadanie spójnego formatowania/układu pomaga w czytelności. – Chris

0

W moim zespole zaimplementowaliśmy zasady check-in, które wykonują AStyle.exe na wszystkich kodach przed odprawą, możesz pobrać AStyle z sourceforge. Tak, jesteśmy tacy, którzy podobnie jak cały kod w projektach mają to samo formatowanie i styl, i tak, jest to łatwe do zrobienia ze skrótami w VS. Zaletą stylizacji przed odprawą jest fakt, że podczas porównywania wersji tego samego pliku format nie zmienił się w zależności od programisty, który dokonał odprawy.

Powiązane problemy