- 1
- 2
// FxCop does not allow the string "Uri" in a method name that does not return a Uri object.
public static string To_U_r_i_TypeString(DeviceType type)-
C# / Говнокод #12363
+114
Запостил:
dirtygopher,
26 Декабря 2012
Follow us!
Если оно будет транслейтить код в lisp Scheme, то даже наоборот слишком сложно.
@SuppressCop("uri")
Исключения есть из любых правил. Я, конечно же, имею в виду обоснованные исключения, а не "мне хочется назвать эту функцию toUriTypeString". Поэтому в FxCop должен быть механизм (и он есть!), чтобы не выпендриваясь в стиле to_u_r_i_TypeString указать, что я выслушал требования, но в моей ситуации они не актуальны. И еще необходима возможность просмотреть список подавленных предупреждений (скорее всего и такая фича тоже есть).
А отключать полезную утилиту и не юзать ее из-за одного false-positive - глупость какая-то (как впрочем и попытки обойти требования через жопу, как в топике, вместо банального SuppressWarning).
:(
Интересно, а какая связь между Microsoft.WindowsMobile.DirectX.Direct3D .DeviceType и URIFormattedString?
- Нуб отключает все ворнинги и не юзает lint'ы и fxcop'ы считая, что они не нужны и показывают всякую херню.
- Наломав дров набравшись опыта он включает ворнинги до упора и бездумно пытается исправлять все-все ворнинги, при этом он боится их подавлять, ведь это же "стандарты" и "их писали не дураки".
- В конце-концов программист понимает, что все эти ворнинги существуют не для того, чтобы усложить ему жизнь, и фанатично терять часы на их исправление, а для того чтобы помочь ему обнаружить возможные ошибки, и понять что он делает не так. Он внимательно читает ворнинги и советы FxCop'а, и осознанно подавляет те, которые неактуальны в его ситуации.
Пример: android lint вчера сказал мне, что создавать SimpleDateFormat вручную некошерно, и следует воспользоваться стандартными инстансами, которые уже корректно настроены на пользовательскую локаль. Хороший совет? В 99% случаев да. Но не в моем, т.е. мне действительно нужна была дата в конкретном, жестко зафиксированном в ТЗ формате.
> Интересно, а какая связь между Microsoft.WindowsMobile.DirectX.Direct3D .DeviceType и URIFormattedString?
Да хрен бы его знал, я про пример из топика не хочу спорить. Это естественно не тот случай, в котором нужно подавлять ворнинг.
переходим на троичные компы, посаны.
потому что бинарный и семеричный как бы взаимоисключащие вещи
А ещё 7 это:
&87
Скорее "упоротый".
Возможно вы имели в виду именно битардный.
Мне вот андроидовый линт очень нравится, хоть иногда и выдает ворнинги не в тему. Очень годные советы выдает, особенно для только начинающего разбираться в платформе, такого как я.
Ну это уже имхо мазохизм, мешающий работать. Проще иногда, когда никаких идей нету, садиться и вычищать ворнинги.
Есть непридуманная история про пакистанскую девочку Шилпу, которая как-то попала к нам в проект подмастерьем. Она была, ну по крайней мере поначалу, очень исполнительным и трудолюбивым сотрудником. В AS3 есть свое подобие lint'a - FlexPMD. Эта... замечательная утилита определяет все слушатели событий (в которых есть обязательный аргумент - событие), как функции с неиспользуемыми аргументами. Т.как в проекте предупреждений от этой утилиты было несколько тыщ, то девочке отдали на поправить, ну, чтобы познакомить с проектом и вообще, с инструментами...
В следующем коммите все слушатели событий были либо удалены, либо нерабочие.
Ну откатили коммит, провели девочке инструктаж о том, что она сделала не так, и как надо делать, и все счастливы. Тоже мне проблема.
> как функции с неиспользуемыми аргументами
Ненавижу, кстати, этот ворнинг. В крестах очень много виртуальных функций им помечается, и толку от него почти нет, из-за огромного количества false-positive ;( Приходится или отключать его совсем, или давить через (void)param или Q_UNUSED(param).
P.S. А какого ж хрена вы этот ворнинг не отключаете совсем, или не подавляете в каждой функции, где он вылезает? Не вижу никакого смысла в стенах ворнингов, выдающихся при каждом старте линта. Среди них же полезные ворнинги потеряются, и внимание программиста рассеится из-за того что каждый раз их пролистывать...
P.P.S. А, понял, ей и отдали этот проект на зачистку ;)
У линта есть дефолтные настройки и, конечно, их можно было заменить, но всем настолько было наплевать, (особенно ввиду того, что ошибок было ну просто очень много), что никто и не обращал внимания. Кроме того, он эти ошибки отрватительно распечатывает, к его распечаткам нужен еще отдельный просматриватель. Ну, а когда, опять же, ошибок очень много то как ни распечатай, все равно после пары страниц скучно станет.
Инфаркт... ну кто в этом виноват? Не девочка конечно же. А тимлид который не пояснил про системы контроля версий, и не проследил за новичком, не занимался code review хотя бы поверхностно.
Инфаркт - это когда вынес таблицу из боевой базы... А код одной командой откатывается.
1. Нанять бойцов с оДеска или Ланца и в экстримально сжатые сроки написать как можно больше кода, используя как можно больше барахла от третьих лиц.
2. Нанять дочку соседа на поддержку проекта, предварительно распросчавшись с бригадой, и потеряв какую-то часть исходников.
3. Понять, что дальше так жить нельзя, и попытаться нанять на постоянную работу кого-нибудь более-менее знающего.
(На самом деле пункты 1-2 могут повторяться до того, как дойдет до 3).
Когда такой проект попадает в руки, то нужно как-то бороться с тяжелым наследием, ну и линт, как одна из попыток что-то сделать. Но как правило, только привести проект в состояние, когда линт вообще может обработать все исходники - само по себе непосильный труд... Девочку тогда и брали в штат для того, чтобы разгрузить более опытных.
Ну и жалко ее было, человек старался, она пару недель потратила на свой первый коммит...
Вот в этом и проблема. Недосмотрели. Не спросили ни разу как идет работа. Ну кто ж так с новичками поступает...
Вот в следующий раз не поленитесь, заведите приватную репу на каком-нибудь битбакете или у себя на сервере, дайте новому работнику доступ на запись, и поясните, что каждый день нужно в обязательном порядке пушить все что было сделано.
Поверьте, и работа будет идти намного эффективнее, и не потеряете наработки, если сотрудник забьет и свалит до окончания срока, и если что случится - проблемы можно будет заметить до того как они станут фатальными. Полчасика в день, потраченные на просмотр коммитов, имхо не будут потрачены в пустую...
Виноват наставник, а не девочка
Выдавать ворнинг:
@SuppressCrap(["china","copy-paste"])
Еще полезно детектить всякие велосипеды:
@SuppressCrap("php-dates")
>CRITICAL ERROR: статическую переменную с маленькой буквы
Лол. Вот если бы еще checked exceptions на ворнинги заменить.
Ну да, какой-нибудь атрибутик в виде @SuppressException(IOException), который заставляет компилер завернуть чекед исключение в RuntimeException, чтобы не писать это говно руками.
все нормальные жабозаменители (clojure, scala, groovy) выпилили checked exceptions
С#
>выпилили checked exceptions
Один из недостатков исключений, описываемых Тарасом - непонятно что и где вылезет.
Не-не. Это оверхед в виде лишнего объекта.
JVMу на эти checked исключения насрать. Просто чтоб компилер собирал.
Сам я вообще никогда их не заворачиваю. А кидаю тот же unchecked через хак.
Можно примерчик?
Самое простое конечно Thread.stop(e). Но мы не ищем легких путей.
An additional danger of this method is that it may be used to generate exceptions that the target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). Прелестный метод.
> оверхед в виде лишнего объекта
Кстати, а стоят ли эти хаки того? Куча в яве шустрая, исключения достаточно редки (если кидать их только в исключительных ситуациях, а не по-питонски)...
>Прелестный метод.
Та да.
Вот потому надо всегда в каком-то корневом методе писать catch(Throwable)
http://www.youtube.com/watch?v=G7YiwTpQdT8
А потом еще разворачивать вложенные исключения.
И тип херится. А так можно ловить тот же IOException, если хочется.
И я уверен на 99% что моя статика в посте ниже заинлайнится, так что оверхеда нет.
Ну можно экономить на спичках хотя бы так:
> Ну можно экономить на спичках хотя бы так
Ну да, в трассе некошерно смотрятся все эти caused by. Но с другой стороны top level заглушек, отлавливающих все-все-все в программе не так много. Можно уж пару-тройку раз вытряхнуть из пойманного экцепшена cause.
> если хочется
Ну судя по превращению в анчекед не особо и хочется...
> И я уверен на 99% что моя статика в посте ниже заинлайнится, так что оверхеда нет.
Кстати, а можно ли как-то в яве посмотреть, чего там наджитил джит, или это совсем черный ящик?
https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
Кстати вот всё хочу проверить как инлайнится полиморфизм и всякие виртуальные методы унаследованные от интерфейсов типа String.length(), а руки не доходят.
Только по-хорошему надо с включенным -server проверять.
http://ideone.com/iZwMmh
Че-то я туплю, почему каст Exception в RuntimeException в предпоследней строке не падает...
Потому что это тупо синтаксический сахар, и на самом деле там получается каст не в RuntimeException, а всего лишь в Throwable (т.к. T extends Throwable), а компилятору заткнули рот саппрес ворнингом, чтобы он не ругался на каст в хуй пойми что (без саппресса он бы съел только RuntimeException e)?
Магия генериков. Чудеса тут: <RuntimeException>
Есть еще способ. Можно вообще без ворнингов и депрекейшнов написать.
Но он некрасивый, требует ресурсов и не инлайнится.
Так точно!
Так это по сути неотключабельная проверка компилера - вот это основной недостаток.
В подтреде речь и идет о неотключаемых чекерах и инспекторах.
Например хочу сделать какой-то хак, я знаю что так делать нехорошо, но понимаю что вот здесь мне он _нужен_.
А компилер не дает. Потому что слишком умный.
Никто не любит слишком умных.
http://rghost.ru/42605788
Суть такова. Можно поставить Ignore, Warning, Error.
И если пользователь поставил error, то не дает компилить. Хочешь warningи жолтые набигают. А уж в коде их глушить: @SuppressWarnings("checked exceptions")
Можно вообще забить. Джва года жду такую опцию.
Там почти в каждом методе (даже в put!) может выброситься JSONException, который надо обрабатывать. По какой же причине он кидает это исключение?
Методы put: Throws: JSONException - If the key is null.. WTF??!! непроверяемый NullPointerException чем не угодил? В конце-концов если я в качестве ключа передал null, то мой код явно невменяем, и заслуживает рантайм экцепшена...
При всем уважении к долбоёбам имею подозрения что писал Крокфорд. JSONObject лютый олдскул. Гумно еще в детский сад ходил когда её написали. Тогда checked был в моде.
Достаточно неделю поработать с Connection Statement и ResultSet как начинается страшная аллергия.
Без удобных либ-обёрток в жабе ловить вообще нечего.
Gson батенька, gson. Хотя для андроида так просто не прокатит, согласен.
Понятно, тогда простительно.
Да на самом деле там можно приложить пачку jar'ов с нужными либами к проекту, и при сборке они упакуются в dex. Скорее всего и GSON можно таким образом туда пропихнуть. Просто влом ради джвух мест, в которых он используется.
> ResultSet
SQLFeatureNotSupportedException порожден от Exception?! Мда, хардкор такой хардкор, имхо кинули бы UnsupportedOperationException да и все... Может я чего-то в жабе не понимаю?
Исключения в любом языке - это плохо, потому что в жабе они проверяемые и это никак не отключить.
Не кажется ли вам, сер, что мы видим экстрагированные ЖАБАПРОБЛЕМЫ.
Каст к парамтеру типа в рантайме превращается в каст к Object т.е. просто выбрасывается, т.как примитивы не могут быть параметрами типа.
На самом деле если в корпоративном style guide написано, что статические переменные начинаются с заглавной, и весь остальной код написан в таком стиле, то инспектор все правильно делает.
> в твоём if больше трёх условий!
Ну это опытному программисту кажется, что такой ворнинг только нозит, т.к. опытный программист и сам чувствует, когда 3 условия в ифе это плохо, а когда можно написать 5-10.
А вот для неопытного джуниора, пытающегося запихать в один иф какое-нибудь говнище, это вполне полезный намек.
P.S. Вот мне кажется, что это должно работать как-то так - не нравится придирка инспектора - подавляешь ее. Затем более старший и опытный товарищ просматривает списки подавленных ворнингов, и или оставляет как есть, или объясняет подавившему что он делает не так, или же, если имеет такое право, вносит изменения в настройки инспектора...
Ну уж нет. Это перебор, даже языков с кучей граблей.
-Wall навеки.
как-то так еще
Умело бы оно еще не показывать этот ворнинг на виртуальных методах, но показывать на остальных - цены бы не было.
А на задовызовах ты либо пиши в заголовке только тип параметра, без названия, либо в начала метода пиши (void)foo, либо
Последнее из Ады
Крестоблядство же, в сишке так нельзя.
> либо в начала метода пиши (void)foo
Ну собственно так и делаю, а в Qt использую макрос Q_UNUSED, который раскрывается в тот же код.
при этом не вижу причин, почему толоконные лбы из сишного комитета продолжают протаскивать это убогое требование
> в Qt использую макрос Q_UNUSED
в 2 раза длиннее, чем написать void, засоряет листинг капслоком - в нем хоть есть преимущество перед void?
Нуб: автор явно хотел что-то этим сказать, но что? Надо бы загуглить.Профи: ага! Функция принимает координаты и цвет, но автор не использует их в данном методе.
Нуб наводит мышку на Q_UNUSED и читает там: Indicates to the compiler that the parameter with the specified name is not used in the body of a function. This can be used to suppress compiler warnings while allowing functions to be defined with meaningful parameter names in their signatures.
P.S. Реализация Q_UNUSED (оказывается не все так безоблачно с кастом в void):P.P.S. Терпеть не могу код, в котором опустили имена аргументов в реализации функции, особенно если мне надо один из них поюзать, и приходится искать в хидере\доке как же он назывался, и копипастить его имя... Видимо стандартизаторы думают так же.
даже истеричному компилятору
всем, кроме сишкоблядского комитета
P.S. Да и меня эти закомментаренные аргументы бесят больше чем Q_UNUSED/(void). Хотя дело вкуса, и комменты действительно втыкаются одним нажатием хоткея (ctrl-/ в креаторе).
и чьи же это проблемы?
если честно, ни разу за 10 лет не было такого, что ворнинг unused parameter реально помог
только раздражает
если пишешь функцию на 10 PgDn и десятком output аргументов, один из которых забываешь присвоить (по сути, единственная гипотетическая польза от этого ворнинга) - зачем должны страдать остальные, не делающие так, но пользующие -Wall
как для меня - и void и Q_UNUSED - плохо пахнущие костыли, только загрязняют код
Боятся пропустить и не выдать какой-нибудь ворнинг из-за слишком тонкой крестограни между input и output параметрами?
Те же инты, содержащие хендл файла/сокета, открытого на запись, или смартпоинтеры, переданные по значению, или конст ссылка на вектор из функций, это input или output? Формально input, но по смыслу могут оказаться обязательным output'ом.
Тут, наверное, нужна маркировочка на первом описании виртуального метода, или на прототипе для колбеков, в которой помечается, какие аргументы важны, и их не стоит игнорировать. Вот только по ним и выдавать подобный ворнинг...
А для невиртуального метода и не коллбека этот ворнинг даже полезен, т.к. там аргументы не юзают разве что для совместимости со старым кодом.
Ну еще гипотетические опечатки из-за копипасты, когда в аргументах были x и y, а в коде поюзал только x джважды.
> зачем должны страдать остальные, не делающие так, но пользующие -Wall
Х.з. видимо они страдают от незнания -Wno-unused-parameter?
Хм, сделал корявый файл без энтера после закрывающей скобки. Откомпилил - ворнинга нет. Видимо в gcc 4 его убрали, т.к. последний раз я видел его только в gcc 3+ под ARM, и там, если мне не изменяет память, он не отключался, и лечился только добавлением энтера в конец файла.
P.S. Файл без энтера в конце корявый не только потому, что его gcc не понимает. Его и многие другие никсовые тулзы не любят, дифф например пишет "В конце файла нет новой строки", а cat нескольких таких файлов клеит их через жопу (последняя строка первого и первая следующего слипаются).
ну а cat работает верно - нет переноса, надо клеить без переноса
Ну к нему никаких претензий нет, для него это просто двоичные файлы. Я просто хотел привести пример, что файлы без конца строки в конце не всегда айс.
P.S. А еще такие файлы прикольно читаются fgets'ом, ломая нубам лабы...
Хотя он может приводить к тихому переполнению. Так что надо смотреть по специфике кода и личным препочтениям.
А этот ворнинг не мусор. Он спасает от вот такой дурацкой ситуации: https://ideone.com/ZY2zAf. Так что отключать его я бы не стал, да и выдается он не всегда, а только когда есть риск.
Если разрядность знакового числа больше разрядности беззнакового, то, согласно стандарту каст пойдет в сторону знакового инта, и ни проблемы ни ворнинга не будет. Если же разрядность беззнакового больше либо равна разрядности знакового - каст пойдет в unsigned, вместе с потенциальной траблой и ворнингом.
Вот за это вот я не люблю си и плюсы - за то что наступить на грабли можно даже в сравнении двух целых чисел.