1. C# / Говнокод #12363

    +114

    1. 1
    2. 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)

    Запостил: dirtygopher, 26 Декабря 2012

    Комментарии (96) RSS

    • С требованиями FxCop согласен.
      Ответить
    • // FxCop does not allow foul words in strings
      MessageBox.Show("Some sh*t happened");
      Ответить
      • MessageBox.Show("Some urina happened");
        Ответить
        • Ну это же не имя метода, ругаться на uri не будет.
          Ответить
        • Я тоже хотел спросить про что-нибудь типа GetUrineAmount, но предположил, что полицейский все же отличит Urine от Uri.
          Ответить
    • Назвать ToScheme - это слишком просто и не приносит сладкого чувства удовлетворения от того, что FxCop остался с носом.
      Ответить
      • > Назвать ToScheme - это слишком просто
        Если оно будет транслейтить код в lisp Scheme, то даже наоборот слишком сложно.
        Ответить
    • Кстати, в FxCop всяко же есть возможность подавить сообщения, которые программист считает неправильными? Это было бы всяко лучше, чем эта херь с подчеркиваниями...

      @SuppressCop("uri")
      Ответить
    • Если не нравятся требования FxCop - просто отключите эту утилиту и не понтуйтесь: Ваши привычки НЕ соответствуют корпоративным стандартам.
      Ответить
      • > просто отключите эту утилиту и не понтуйтесь: Ваши привычки НЕ соответствуют корпоративным стандартам

        Исключения есть из любых правил. Я, конечно же, имею в виду обоснованные исключения, а не "мне хочется назвать эту функцию toUriTypeString". Поэтому в FxCop должен быть механизм (и он есть!), чтобы не выпендриваясь в стиле to_u_r_i_TypeString указать, что я выслушал требования, но в моей ситуации они не актуальны. И еще необходима возможность просмотреть список подавленных предупреждений (скорее всего и такая фича тоже есть).

        А отключать полезную утилиту и не юзать ее из-за одного false-positive - глупость какая-то (как впрочем и попытки обойти требования через жопу, как в топике, вместо банального SuppressWarning).
        Ответить
        • Разве что по копропротивным правилам за предупреждения от FxCop штрафуют. А SuppressWarning - ах вы еще и обмануть пытаетесь?

          :(
          Ответить
        • "Вы думаете что вы исключительный человек, что общие правила вас касаются" (c)начальник - вечно опаздывающему сотруднику.
          Интересно, а какая связь между Microsoft.WindowsMobile.DirectX.Direct3D .DeviceType и URIFormattedString?
          Ответить
          • А для чего по-вашему в FxCop показывается около каждого правила что-то типа достоверности? А ведь как раз потому, что он может ошибаться, как и любая другая прога, да и даже программисты которые ее писали. И в реальной жизни нет таких правил, из которых нет исключений.

            - Нуб отключает все ворнинги и не юзает lint'ы и fxcop'ы считая, что они не нужны и показывают всякую херню.
            - Наломав дров набравшись опыта он включает ворнинги до упора и бездумно пытается исправлять все-все ворнинги, при этом он боится их подавлять, ведь это же "стандарты" и "их писали не дураки".
            - В конце-концов программист понимает, что все эти ворнинги существуют не для того, чтобы усложить ему жизнь, и фанатично терять часы на их исправление, а для того чтобы помочь ему обнаружить возможные ошибки, и понять что он делает не так. Он внимательно читает ворнинги и советы FxCop'а, и осознанно подавляет те, которые неактуальны в его ситуации.

            Пример: android lint вчера сказал мне, что создавать SimpleDateFormat вручную некошерно, и следует воспользоваться стандартными инстансами, которые уже корректно настроены на пользовательскую локаль. Хороший совет? В 99% случаев да. Но не в моем, т.е. мне действительно нужна была дата в конкретном, жестко зафиксированном в ТЗ формате.

            > Интересно, а какая связь между Microsoft.WindowsMobile.DirectX.Direct3D .DeviceType и URIFormattedString?
            Да хрен бы его знал, я про пример из топика не хочу спорить. Это естественно не тот случай, в котором нужно подавлять ворнинг.
            Ответить
            • Ну конечно исключения могут быть - логика человека не должна быть бинарной. Бинарная логика хороша для журналистов, но только не для творческих профессий. На счет стандартов, лично я всегда старательно выбираю имена, что окупается потом сторицей. Использую какие-нибудь стандарты, например из книги "Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек". Раньше использовал книгу Франческо Б и Джузеппе Д. Обычно любой инспектор заглатывает мой код почти без ворнингов.
              Ответить
              • В первой упомянутой книге на каждое правило - несколько мнений. Что лишний раз подчеркивает то что мыслительный процесс не должен быть бинарным.
                Ответить
        • На предыдущем месте работы заставляли чинить ворнинги Sonar, который больше 3 условий в if считал критической ошибкой. Ненавижу я эти дурацкие инспекторы. Особенно когда их настраиваю не я.
          Ответить
          • Инспекторы и линты это очень годная тулза, если их юзать не в режиме "фанатик, исправляющий все-все-все".

            Мне вот андроидовый линт очень нравится, хоть иногда и выдает ворнинги не в тему. Очень годные советы выдает, особенно для только начинающего разбираться в платформе, такого как я.
            Ответить
            • я не против вменяемых инспекций, типа тех, что предлагает IntelliJ Idea по умолчанию, некоторым вообще цены нет. Сишку и плюсы компиляю только с -Werror. Но "CRITICAL ERROR: в твоём if больше трёх условий!" и "CRITICAL ERROR: ты назвал статическую переменную с маленькой буквы!" вгоняют меня в депрессию.
              Ответить
              • > Сишку и плюсы компиляю только с -Werror
                Ну это уже имхо мазохизм, мешающий работать. Проще иногда, когда никаких идей нету, садиться и вычищать ворнинги.
                Ответить
                • > Проще иногда, когда никаких идей нету, садиться и вычищать ворнинги.
                  Есть непридуманная история про пакистанскую девочку Шилпу, которая как-то попала к нам в проект подмастерьем. Она была, ну по крайней мере поначалу, очень исполнительным и трудолюбивым сотрудником. В AS3 есть свое подобие lint'a - FlexPMD. Эта... замечательная утилита определяет все слушатели событий (в которых есть обязательный аргумент - событие), как функции с неиспользуемыми аргументами. Т.как в проекте предупреждений от этой утилиты было несколько тыщ, то девочке отдали на поправить, ну, чтобы познакомить с проектом и вообще, с инструментами...
                  В следующем коммите все слушатели событий были либо удалены, либо нерабочие.
                  Ответить
                  • > В следующем коммите все слушатели событий были либо удалены, либо нерабочие.
                    Ну откатили коммит, провели девочке инструктаж о том, что она сделала не так, и как надо делать, и все счастливы. Тоже мне проблема.

                    > как функции с неиспользуемыми аргументами
                    Ненавижу, кстати, этот ворнинг. В крестах очень много виртуальных функций им помечается, и толку от него почти нет, из-за огромного количества false-positive ;( Приходится или отключать его совсем, или давить через (void)param или Q_UNUSED(param).

                    P.S. А какого ж хрена вы этот ворнинг не отключаете совсем, или не подавляете в каждой функции, где он вылезает? Не вижу никакого смысла в стенах ворнингов, выдающихся при каждом старте линта. Среди них же полезные ворнинги потеряются, и внимание программиста рассеится из-за того что каждый раз их пролистывать...
                    P.P.S. А, понял, ей и отдали этот проект на зачистку ;)
                    Ответить
                    • Ничего себе "не проблема", у девочки чуть инфакрт сердца и инсулть мозга не случились.
                      У линта есть дефолтные настройки и, конечно, их можно было заменить, но всем настолько было наплевать, (особенно ввиду того, что ошибок было ну просто очень много), что никто и не обращал внимания. Кроме того, он эти ошибки отрватительно распечатывает, к его распечаткам нужен еще отдельный просматриватель. Ну, а когда, опять же, ошибок очень много то как ни распечатай, все равно после пары страниц скучно станет.
                      Ответить
                      • Ну если всем наплевать, и линт каждый раз выдает по 2 листа... то зачем грызть кактус и использовать его? Судя по такому обращению с ним он вам тупо не нужен.

                        Инфаркт... ну кто в этом виноват? Не девочка конечно же. А тимлид который не пояснил про системы контроля версий, и не проследил за новичком, не занимался code review хотя бы поверхностно.

                        Инфаркт - это когда вынес таблицу из боевой базы... А код одной командой откатывается.
                        Ответить
                        • В отличие от десктопных проектов, для флеша характерна следующая модель развития:
                          1. Нанять бойцов с оДеска или Ланца и в экстримально сжатые сроки написать как можно больше кода, используя как можно больше барахла от третьих лиц.
                          2. Нанять дочку соседа на поддержку проекта, предварительно распросчавшись с бригадой, и потеряв какую-то часть исходников.
                          3. Понять, что дальше так жить нельзя, и попытаться нанять на постоянную работу кого-нибудь более-менее знающего.
                          (На самом деле пункты 1-2 могут повторяться до того, как дойдет до 3).
                          Когда такой проект попадает в руки, то нужно как-то бороться с тяжелым наследием, ну и линт, как одна из попыток что-то сделать. Но как правило, только привести проект в состояние, когда линт вообще может обработать все исходники - само по себе непосильный труд... Девочку тогда и брали в штат для того, чтобы разгрузить более опытных.
                          Ну и жалко ее было, человек старался, она пару недель потратила на свой первый коммит...
                          Ответить
                          • > Ну и жалко ее было, человек старался, она пару недель потратила на свой первый коммит...
                            Вот в этом и проблема. Недосмотрели. Не спросили ни разу как идет работа. Ну кто ж так с новичками поступает...
                            Ответить
                            • Ну а кто ж знал... другому обычно и в голову не прийдет, что такое можно сделать. Тоесть, ну, конечно, можно было ожидать, что случится что-то плохое, но как правило ждешь ведь, что будет ну пара каких-нибудь ошибок, ну там даже пусть 50% брака... а тут получилось все впустую практически. Да, и она работала удаленно, а на вопросы отвечала уклончиво, типа "да, да, все хорошо, вот исправила Х предупреждений" и т.д...
                              Ответить
                              • > Да, и она работала удаленно, а на вопросы отвечала уклончиво, типа "да, да, все хорошо, вот исправила Х предупреждений" и т.д...
                                Вот в следующий раз не поленитесь, заведите приватную репу на каком-нибудь битбакете или у себя на сервере, дайте новому работнику доступ на запись, и поясните, что каждый день нужно в обязательном порядке пушить все что было сделано.

                                Поверьте, и работа будет идти намного эффективнее, и не потеряете наработки, если сотрудник забьет и свалит до окончания срока, и если что случится - проблемы можно будет заметить до того как они станут фатальными. Полчасика в день, потраченные на просмотр коммитов, имхо не будут потрачены в пустую...
                                Ответить
                  • >Шилпу
                    Виноват наставник, а не девочка
                    Ответить
              • Тут поциент был, в районе #6ххх. Жаловался на то что студия не компилит 128 вложенных ifов. Так что некий смысл есть. Например когда в методе 40 параметров, или 127 условий в ифе - это разумно.
                Выдавать ворнинг:
                @SuppressCrap(["china","copy-paste"])
                Еще полезно детектить всякие велосипеды:
                @SuppressCrap("php-dates")

                >CRITICAL ERROR: статическую переменную с маленькой буквы
                Лол. Вот если бы еще checked exceptions на ворнинги заменить.
                Ответить
                • > Лол. Вот если бы еще checked exceptions на ворнинги заменить.

                  Ну да, какой-нибудь атрибутик в виде @SuppressException(IOException), который заставляет компилер завернуть чекед исключение в RuntimeException, чтобы не писать это говно руками.
                  Ответить
                  • > заставляет компилер завернуть чекед исключение в RuntimeException
                    все нормальные жабозаменители (clojure, scala, groovy) выпилили checked exceptions
                    Ответить
                    • >жабозаменители
                      С#
                      >выпилили checked exceptions
                      Один из недостатков исключений, описываемых Тарасом - непонятно что и где вылезет.
                      Ответить
                  • >завернуть чекед исключение в RuntimeException,
                    Не-не. Это оверхед в виде лишнего объекта.
                    JVMу на эти checked исключения насрать. Просто чтоб компилер собирал.
                    Сам я вообще никогда их не заворачиваю. А кидаю тот же unchecked через хак.
                    Ответить
                    • > через хак
                      Можно примерчик?
                      Ответить
                      • Да постил уже.
                        Самое простое конечно Thread.stop(e). Но мы не ищем легких путей.
                        Ответить
                        • > 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). Прелестный метод.

                          > оверхед в виде лишнего объекта
                          Кстати, а стоят ли эти хаки того? Куча в яве шустрая, исключения достаточно редки (если кидать их только в исключительных ситуациях, а не по-питонски)...
                          Ответить
                          • >(including checked exceptions that the thread could not possibly throw, were it not for this method).
                            >Прелестный метод.
                            Та да.
                            Вот потому надо всегда в каком-то корневом методе писать catch(Throwable)
                            Ответить
                          • >Кстати, а стоят ли эти хаки того?
                            А потом еще разворачивать вложенные исключения.
                            И тип херится. А так можно ловить тот же IOException, если хочется.
                            И я уверен на 99% что моя статика в посте ниже заинлайнится, так что оверхеда нет.

                            Ну можно экономить на спичках хотя бы так:
                            public 	static 
                            	RuntimeException toUnchecked(Throwable e){
                            		return (e instanceof RuntimeException) 
                            			? (RuntimeException) 	e 
                            			: new RuntimeException (e);
                            	}
                            Ответить
                            • > А потом еще разворачивать вложенные исключения.
                              > Ну можно экономить на спичках хотя бы так
                              Ну да, в трассе некошерно смотрятся все эти caused by. Но с другой стороны top level заглушек, отлавливающих все-все-все в программе не так много. Можно уж пару-тройку раз вытряхнуть из пойманного экцепшена cause.

                              > если хочется
                              Ну судя по превращению в анчекед не особо и хочется...

                              > И я уверен на 99% что моя статика в посте ниже заинлайнится, так что оверхеда нет.
                              Кстати, а можно ли как-то в яве посмотреть, чего там наджитил джит, или это совсем черный ящик?
                              Ответить
                              • Для хотспота есть. Даже с пояснениями.
                                https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly
                                Кстати вот всё хочу проверить как инлайнится полиморфизм и всякие виртуальные методы унаследованные от интерфейсов типа String.length(), а руки не доходят.

                                Только по-хорошему надо с включенным -server проверять.
                                Ответить
                      • Вот труЪ-способ. Обратите внимание на тарасоформатирование.
                        http://ideone.com/iZwMmh
                        public	static 
                        void 	throwe(Throwable e) 
                        {
                        	Main.<RuntimeException>trickyThrow(e);
                        }
                        	
                        @SuppressWarnings("unchecked")
                        public 	static <T extends Throwable>
                        void 	trickyThrow(Throwable e)
                        throws 	T 
                        {
                            throw (T) e;
                        }
                        Ответить
                        • Интересный способ.

                          Че-то я туплю, почему каст Exception в RuntimeException в предпоследней строке не падает...

                          Потому что это тупо синтаксический сахар, и на самом деле там получается каст не в RuntimeException, а всего лишь в Throwable (т.к. T extends Throwable), а компилятору заткнули рот саппрес ворнингом, чтобы он не ругался на каст в хуй пойми что (без саппресса он бы съел только RuntimeException e)?
                          Ответить
                          • Ну да, примерно так. Никакого каста не происходит.
                            Магия генериков. Чудеса тут: <RuntimeException>

                            Есть еще способ. Можно вообще без ворнингов и депрекейшнов написать.
                            Но он некрасивый, требует ресурсов и не инлайнится.
                            Ответить
                            • Блин - вот чекед ексепшен сделан во имя добра и чтобы исключения проверить во время компиляции, чтобы не было непредсказуемости, чтобы ничего не забыть. А тут вылазят такие кастылища... Неужели благими намерениями выстлана дорога в аду?
                              Ответить
                              • >Неужели благими намерениями выстлана дорога в аду?
                                Так точно!
                                Ответить
                              • >проверить во время компиляции
                                Так это по сути неотключабельная проверка компилера - вот это основной недостаток.
                                В подтреде речь и идет о неотключаемых чекерах и инспекторах.

                                Например хочу сделать какой-то хак, я знаю что так делать нехорошо, но понимаю что вот здесь мне он _нужен_.
                                А компилер не дает. Потому что слишком умный.

                                Никто не любит слишком умных.
                                Ответить
                                • Да, все верно. Заворачивая чекед экцепшн в потомок RuntimeException'а или же перевбрасывая его с помощью хака я показываю, что обработка этого исключения не имеет для меня никакого смысла. И для таких случаев пригодился бы @SuppressException(IOException), убирающий проверку, чтобы не юзать грязные хаки...
                                  Ответить
                                  • Та в коде это вообще не нужно. В среде должно всё настраиваться( опцией компилера само собой).
                                    http://rghost.ru/42605788
                                    Суть такова. Можно поставить Ignore, Warning, Error.
                                    И если пользователь поставил error, то не дает компилить. Хочешь warningи жолтые набигают. А уж в коде их глушить: @SuppressWarnings("checked exceptions")
                                    Можно вообще забить. Джва года жду такую опцию.
                                    Ответить
                                    • Вот, кстати, меня эти чекед исключения по началу особо не бесили, пока я не столкнулся с JSONObject, который писал какой-то, простите, долбоеб.

                                      Там почти в каждом методе (даже в put!) может выброситься JSONException, который надо обрабатывать. По какой же причине он кидает это исключение?

                                      Методы put: Throws: JSONException - If the key is null.. WTF??!! непроверяемый NullPointerException чем не угодил? В конце-концов если я в качестве ключа передал null, то мой код явно невменяем, и заслуживает рантайм экцепшена...
                                      Ответить
                                      • > столкнулся с JSONObject
                                        При всем уважении к долбоёбам имею подозрения что писал Крокфорд. JSONObject лютый олдскул. Гумно еще в детский сад ходил когда её написали. Тогда checked был в моде.
                                        Достаточно неделю поработать с Connection Statement и ResultSet как начинается страшная аллергия.
                                        Без удобных либ-обёрток в жабе ловить вообще нечего.
                                        Gson батенька, gson. Хотя для андроида так просто не прокатит, согласен.
                                        Ответить
                                        • > JSONObject лютый олдскул.
                                          Понятно, тогда простительно.

                                          Да на самом деле там можно приложить пачку jar'ов с нужными либами к проекту, и при сборке они упакуются в dex. Скорее всего и GSON можно таким образом туда пропихнуть. Просто влом ради джвух мест, в которых он используется.

                                          > ResultSet
                                          SQLFeatureNotSupportedException порожден от Exception?! Мда, хардкор такой хардкор, имхо кинули бы UnsupportedOperationException да и все... Может я чего-то в жабе не понимаю?
                                          Ответить
                                      • В общем, поэтому у меня сложилось такое мнение о данном механизме, которое вы уже слышали.
                                        Ответить
                                        • Ну да молодец. Пришел и поставил всех на место.
                                          Исключения в любом языке - это плохо, потому что в жабе они проверяемые и это никак не отключить.
                                          Не кажется ли вам, сер, что мы видим экстрагированные ЖАБАПРОБЛЕМЫ.
                                          Ответить
                          • > каст в хуй пойми что
                            Каст к парамтеру типа в рантайме превращается в каст к Object т.е. просто выбрасывается, т.как примитивы не могут быть параметрами типа.
                            Ответить
              • > ты назвал статическую переменную с маленькой буквы
                На самом деле если в корпоративном style guide написано, что статические переменные начинаются с заглавной, и весь остальной код написан в таком стиле, то инспектор все правильно делает.

                > в твоём if больше трёх условий!
                Ну это опытному программисту кажется, что такой ворнинг только нозит, т.к. опытный программист и сам чувствует, когда 3 условия в ифе это плохо, а когда можно написать 5-10.

                А вот для неопытного джуниора, пытающегося запихать в один иф какое-нибудь говнище, это вполне полезный намек.

                P.S. Вот мне кажется, что это должно работать как-то так - не нравится придирка инспектора - подавляешь ее. Затем более старший и опытный товарищ просматривает списки подавленных ворнингов, и или оставляет как есть, или объясняет подавившему что он делает не так, или же, если имеет такое право, вносит изменения в настройки инспектора...
                Ответить
              • >Сишку и плюсы компиляю только с -Werror.
                Ну уж нет. Это перебор, даже языков с кучей граблей.
                -Wall навеки.
                Ответить
                • -Wextra -Wno-unused-parameter
                  как-то так еще

                  Умело бы оно еще не показывать этот ворнинг на виртуальных методах, но показывать на остальных - цены бы не было.
                  Ответить
                  • На всех пусть показывает.
                    А на задовызовах ты либо пиши в заголовке только тип параметра, без названия, либо в начала метода пиши (void)foo, либо
                    #pragma suppress_warning(unused_parameter, foo)

                    Последнее из Ады
                    Ответить
                    • > пиши в заголовке только тип параметра, без названия
                      Крестоблядство же, в сишке так нельзя.

                      > либо в начала метода пиши (void)foo
                      Ну собственно так и делаю, а в Qt использую макрос Q_UNUSED, который раскрывается в тот же код.
                      Ответить
                      • > в сишке так нельзя
                        при этом не вижу причин, почему толоконные лбы из сишного комитета продолжают протаскивать это убогое требование
                        > в Qt использую макрос Q_UNUSED
                        в 2 раза длиннее, чем написать void, засоряет листинг капслоком - в нем хоть есть преимущество перед void?
                        Ответить
                        • Поясню при помощи небольшой сценки. Нуб и Профи устроились на работу, и получили исходники проекта, который до этого они никогда не видели. В один прекрасный момент они наткнулись на функцию foo:
                          int foo(int, int, int) {
                              // ...
                          }
                          Нуб и профи: что это за хуита? Какие аргументы приходят в эту функцию? Придется посмотреть в документации...
                          int foo(int x, int y, int color) {
                              (void)x, y, color;
                              // ...
                          }
                          Профи: ага! Функция принимает координаты и цвет, но автор не использует их в данном методе.
                          Нуб: автор явно хотел что-то этим сказать, но что? Надо бы загуглить.
                          int foo(int x, int y, int color) {
                              Q_UNUSED(x)
                              Q_UNUSED(y)
                              Q_UNUSED(color)
                          }
                          Профи: ага! Функция принимает координаты и цвет, но автор не использует их в данном методе.
                          Нуб наводит мышку на 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):
                          #if defined(Q_CC_INTEL) && !defined(Q_OS_WIN) || defined(Q_CC_RVCT)
                          template <typename T>
                          inline void qUnused(T &x) { (void)x; }
                          #  define Q_UNUSED(x) qUnused(x);
                          #else
                          #  define Q_UNUSED(x) (void)x;
                          #endif
                          P.P.S. Терпеть не могу код, в котором опустили имена аргументов в реализации функции, особенно если мне надо один из них поюзать, и приходится искать в хидере\доке как же он назывался, и копипастить его имя... Видимо стандартизаторы думают так же.
                          Ответить
                          • int foo(int x, int y, int color) {
                                Q_UNUSED(x)
                                Q_UNUSED(y)
                                Q_UNUSED(color)
                            }
                            
                            int foo2(int /*x*/, int /*y*/, int /*color*/) {
                            }
                            выделить с шифтом аргумент и нажать * - экономит время и строки, и всем всё очевидно
                            даже истеричному компилятору
                            всем, кроме сишкоблядского комитета
                            Ответить
                            • Докси смотрит на такие комментарии как на говно, и на выхлопе показывает прелестную сигнатуру: void foo (int, int, int).

                              P.S. Да и меня эти закомментаренные аргументы бесят больше чем Q_UNUSED/(void). Хотя дело вкуса, и комменты действительно втыкаются одним нажатием хоткея (ctrl-/ в креаторе).
                              Ответить
                              • > Докси
                                и чьи же это проблемы?

                                если честно, ни разу за 10 лет не было такого, что ворнинг unused parameter реально помог
                                только раздражает
                                если пишешь функцию на 10 PgDn и десятком output аргументов, один из которых забываешь присвоить (по сути, единственная гипотетическая польза от этого ворнинга) - зачем должны страдать остальные, не делающие так, но пользующие -Wall

                                как для меня - и void и Q_UNUSED - плохо пахнущие костыли, только загрязняют код
                                Ответить
                                • вот кстати на самом деле - почему бы компилятору не отслеживать только output параметры/invokable (*, &, function pointer/has reachable operator ()), ведь только они грозят хоть какой то возможностью ошибиться
                                  Ответить
                                  • > почему бы компилятору не отслеживать только output параметры/invokable

                                    Боятся пропустить и не выдать какой-нибудь ворнинг из-за слишком тонкой крестограни между input и output параметрами?

                                    Те же инты, содержащие хендл файла/сокета, открытого на запись, или смартпоинтеры, переданные по значению, или конст ссылка на вектор из функций, это input или output? Формально input, но по смыслу могут оказаться обязательным output'ом.

                                    Тут, наверное, нужна маркировочка на первом описании виртуального метода, или на прототипе для колбеков, в которой помечается, какие аргументы важны, и их не стоит игнорировать. Вот только по ним и выдавать подобный ворнинг...

                                    А для невиртуального метода и не коллбека этот ворнинг даже полезен, т.к. там аргументы не юзают разве что для совместимости со старым кодом.
                                    Ответить
                                • > по сути, единственная гипотетическая польза от этого ворнинга
                                  Ну еще гипотетические опечатки из-за копипасты, когда в аргументах были x и y, а в коде поюзал только x джважды.

                                  > зачем должны страдать остальные, не делающие так, но пользующие -Wall
                                  Х.з. видимо они страдают от незнания -Wno-unused-parameter?
                                  Ответить
                                  • а есть свич, выключающий "no newline at end"?
                                    Ответить
                                    • > no newline at end
                                      Хм, сделал корявый файл без энтера после закрывающей скобки. Откомпилил - ворнинга нет. Видимо в gcc 4 его убрали, т.к. последний раз я видел его только в gcc 3+ под ARM, и там, если мне не изменяет память, он не отключался, и лечился только добавлением энтера в конец файла.

                                      P.S. Файл без энтера в конце корявый не только потому, что его gcc не понимает. Его и многие другие никсовые тулзы не любят, дифф например пишет "В конце файла нет новой строки", а cat нескольких таких файлов клеит их через жопу (последняя строка первого и первая следующего слипаются).
                                      Ответить
                                      • хотя это требование с++11 (дописывать переносы, если их нет), похоже реально в 4.х убрали (поэкспериментировал на LWS - разницу C++03/C++11 в этом увидел только clang)

                                        ну а cat работает верно - нет переноса, надо клеить без переноса
                                        Ответить
                                        • > ну а cat работает верно
                                          Ну к нему никаких претензий нет, для него это просто двоичные файлы. Я просто хотел привести пример, что файлы без конца строки в конце не всегда айс.

                                          P.S. А еще такие файлы прикольно читаются fgets'ом, ломая нубам лабы...
                                          Ответить
                            • Возможен ещё и такой вариант:
                              int foo(int x, int y, int color) {
                                  x=x;
                                  y=y;
                                  color=color;
                              }
                              Ответить
                              • Но это смотрится еще хуже чем все вышеперечисленное ;)
                                Ответить
                              • Подёргивание конструкторов копирования для нетривиальных типов?
                                Ответить
                                • Хорошо еще, если они правильно написаны, и вменяемо реагируют на такое использование...
                                  Ответить
                  • Да. Всякий мусор надо глушить, тот же -Wno-sign-compare.
                    Хотя он может приводить к тихому переполнению. Так что надо смотреть по специфике кода и личным препочтениям.
                    Ответить
                    • > -Wno-sign-compare
                      А этот ворнинг не мусор. Он спасает от вот такой дурацкой ситуации: https://ideone.com/ZY2zAf. Так что отключать его я бы не стал, да и выдается он не всегда, а только когда есть риск.

                      Если разрядность знакового числа больше разрядности беззнакового, то, согласно стандарту каст пойдет в сторону знакового инта, и ни проблемы ни ворнинга не будет. Если же разрядность беззнакового больше либо равна разрядности знакового - каст пойдет в unsigned, вместе с потенциальной траблой и ворнингом.
                      Ответить
                      • Блеать!
                        Вот за это вот я не люблю си и плюсы - за то что наступить на грабли можно даже в сравнении двух целых чисел.
                        Ответить

    Добавить комментарий