C# - pattern matching - many discards
Наф оно нужно вообще?От куда ж мне знать? :) Но требование такое есть. Будь любезен исполнять.
Проверка на лояльность? Типа, скажи ему регулярно повторять какую-нибудь ненужную фигню, чтобы отнимала время и действовала на нервы. Если согласится, значит покладистый - берём
/**
* identisch zu
* @param adresse AdresseMitLand
*/
public Boolean identischZu(AdresseMitLand adresse) {
return true;
}За неанглийский код нужно убивать. Долго и мучительно.
Ну так это один владелец, не битая, не крашеная...
Где описание параметра, где описание результата? Метод-то публичный.
Зачем разливать воду там, где и по названию метода всё понятно?
Понятно, почему это делают всякие Микрософты и им подобные - у них платят за жопочасы и строчки быдлокода. Они могут потратить недели на обсуждение этих ваших пробелов или табов, проводить многоуровневые исследования фокус-групп, и не написать за месяц ни строчки кода. При этом все - солидные такие шестизнаки. А ваши-то шараги куда со свиным рылом в калашный ряд пруться?
Зачем разливать воду там, где и по названию метода всё понятно?
-----
А шо, ты таки действительно не знаешь? Ну тады шмакай Ф1.
Как зачем? Дырку в интерфейсе затыкает..
Не угадал. Если б он метод из интерфейса имплементировал, у него аннотация @Override была бы.
Все всегда делается в меру понимания исполнителем и чаще всего исполнитель не интересуется архитектурой
Угу,.. исправить, исправили, сейчас работает, а что будет потом уже не интересует.
Обращаешь внимание, - а какого переписывать и так всё работает.
До сих пор всё такое счастье тупо коммитилось, потом проходило 3 года и все сидели чесали репу а нафига ж такое сотворили, и чего хотели этим сказать.
Спасибо
Только это скорей правила оформления кода, чем coding standards. Тут старперы наверняка вперед всех.
Проверка на лояльность? Типа, скажи ему регулярно повторять какую-нибудь ненужную фигню, чтобы отнимала время и действовала на нервы. Если согласится, значит покладистый - берём
А кто оценивает нужность / ненужность фигни? :) Безотносительно этого примера.
С нужностью-ненужностью фигни как с кодом - если через какое-то время никто не может объяснить, зачем эта фигня нужна, значит что-то не так со стандартами этих ваших фигней. Если при этом все продолжают делать эту фигню (потому что "так деды завещали"), то не так уже и с вами. При этом мантра "работает? - не трогай!" не работает.
Только это скорей правила оформления кода, чем coding standards. Тут старперы наверняка вперед всех.
Я под "правилами оформления кода" понимаю правила вроде "строчка не длиннее 140 символов", или "сначала в классе идут публичные, потом приватные" или "после } перенос строки". Но всё равно всё это тоже Coding Convention.
Тут старперы наверняка вперед всех.
Если б. У них у каждого своё мнение. Каждый пишет как ему нравится. Но именно в оформлении без больших расхождений. Потому что разобраться не смогли как настройки форматтера в эклипсе поменять :)
Проверка на лояльность? Типа, скажи ему регулярно повторять какую-нибудь ненужную фигню, чтобы отнимала время и действовала на нервы. Если согласится, значит покладистый - берём
Все эти детали полезны для того, чтобы избежать вкусовщины.
Один вставит юзинг и забудет. Другой будет сортировать изинги по длине. Третий по алфавиту. Четвертый по каким-нибудь другим признакам. И жопа начнется, когда все эти люди начнут (а рано или поздно они начнут) форматировать уже написанное под себя.
разобраться не смогли как настройки форматтера в эклипсе поменять
А тут меньше чем надо? Один раз настроил и пользуй везде. Для шарпа сделано довольно хорошо, предполагаю, что для явы не хуже.
https://www.jetbrains.com/help/idea/configuring-code-style...
Я под "правилами оформления кода" понимаю правила вроде "строчка не длиннее 140 символов", или "сначала в классе идут публичные, потом приватные" или "после } перенос строки". Но всё равно всё это тоже Coding Convention.
Тогда это хрень полная. Вы бетонируете какие-то фарисейские принципы, зачастую мешающие нормальной работе. В некоторых случаях удобно писать, группируя по смыслу - поля и свойства, например. Т.е. приватную и публичную часть рядом друг с другом. А иногда и методы туда же - в инициализацию объекта пихаю реализацию делегата, созданную тут же через лямбду. Типа такого (отвлечённый пример на Сишарпе)
Person somePerson;
public Person SomePerson => somePerson ??= new()
{
Age = 20,
Name = _ => Age > 5 ? Person.DefaultName : "Baby",
Condition = (Guid id, string defaultCondition) =>
{
var realAge = GetRealAge(id);
return realAge > 100 ? "died" : defaultCondition;
},
};
По вашим правилам я должен эти несколько коротких строчек разнести в три разных места класса - приватное поле somePerson в определение полей, свойство для него - в публичные свойства, и ещё в месте для методов написать пару методов для получения имени и состояния. А потом бегать-мотаться по всему классу, выясняя, как же инициализируется свойство. А у меня - всё в одном месте.
А не так давно мы ещё выяснили, что такая запись многим неприемлема - нужно расписать всё с явными геттерами, явной проверкой на налл (без оператора ??=) и без лямбд. Т.е. накатать кода где-то на полэкрана, разнесённого в три разных места класса.
Мне это ещё в плюсах не нравилось - чтобы понять, как работает класс, где у него что находится, нужно открыть минимум ДВА файла. Может, в 80-90-е это и было круто, но сейчас и уже давно это смотрится как костыльный анахронизм, мешающий работать.
Тогда это хрень полная. В некоторых случаях удобно писать...
А в некоторых случаях так, а может и так... в итоге каждый пишет как ему удобно, под настроение на сегодня.
А теперь возьмем команду, в которой каждый пишет как хочет, насколько быстро можно будет читать код другого человека?
Ну а про приведенный код я лучше промолчу 
Zurück
Liste