Contains error and cannot be accepted the previous value is kept instead

Как исправить в Pandas: SettingWithCopyWarning

Одно предупреждение, с которым вы можете столкнуться при использовании pandas:

Это предупреждение появляется, когда pandas сталкивается с чем-то, что называется цепным назначением — сочетанием цепочки и назначения за один шаг.

Важно отметить, что это просто предупреждение , а не ошибка. Ваш код по-прежнему будет выполняться, но результаты могут не всегда соответствовать вашим ожиданиям.

Самый простой способ подавить это предупреждение — использовать следующий фрагмент кода:

В следующем примере показано, как устранить это предупреждение на практике.

Как воспроизвести предупреждение

Предположим, мы создаем следующие Pandas DataFrame:

Теперь предположим, что мы создаем новый DataFrame, который содержит только столбец «A» из исходного DataFrame, и мы делим каждое значение в столбце «A» на 2:

Мы получаем сообщение SettingWithCopyWarning , потому что мы устанавливаем новые значения для столбца «A» в «срезе» исходного фрейма данных.

Однако, если мы посмотрим на созданный нами новый DataFrame, то увидим, что каждое значение было успешно разделено на 2:

Несмотря на то, что мы получили предупреждающее сообщение, Pandas все же сделали то, что мы ожидали.

Как избежать предупреждения

Чтобы избежать предупреждения, рекомендуется использовать синтаксис .loc[индексатор строк, индексатор столбцов] следующим образом:

Новый DataFrame содержит все значения из столбца «A» в исходном DataFrame, разделенные на два, и предупреждающее сообщение не появляется.

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

За подробным объяснением того, почему следует избегать цепного присваивания, обратитесь к онлайн-документации pandas .

Источник

Contains error and cannot be accepted the previous value is kept instead

An IllegalStateException is thrown when no ContextSelector could be set for logback’s StaticLoggerBinder . In principle, this error can only occur when the context selector is expressly specified by the user, and when that context selector cannot not be instantiated correctly.

It should not happen when you are using the default or JNDI context selectors.

This appender no longer admits a layout as a subcomponent, set an encoder instead.

As of logback version 0.9.19, the WriterAppender class has been renamed as OutputStreamAppender , with FileAppender now subclassing the latter. OutputStreamAppender and subclasses now take an Encoder as a subcomponent instead of a Layout .

In practical terms, this means that configuration files need to be changed

or the shorter equivalent (DEPRECATED)

or the shorter equivalent (GOOD)

For layout type other than PatternLayout , for example HTMLLayout , your configuration files need to be changed

We hope to make up for this inconvenience with cool new features which are only possible using encoders. During a transition period, layouts passed as parameter will be automatically wrapped by an encoder so that configuration files in the old format (using a layout instead of encoder) will continue to work unmodified.

No remote host or address is set for SocketAppender

A remote host or address is mandatory for SocketAppender.

You can specify the remote host in the configuration file as follows.

No remote port is set for SocketAppender

A remote port is mandatory for SocketAppender.

You can specify the remote port in the configuration file like this:

No Layout is set for SMTPAppender

A Layout is mandatory for SMTPAppender . It allows SMTPAppender to format logging events before sending an email.

You can specify the Layout in a configuration file as follows:

SMTPAppender is known to work well with PatternLayout and HTMLLayout.

Specified number is not in proper int form, or not expected format.

When you specify the MaxFileSize to be used by the SizeBasedRollingPolicy, logback expects a rather precise format:

• The number has to be an integer
• You can add ‘KB’, ‘MB’ or ‘GB’ after the number.

Here are some correct values: 500KB, 15MB, 2GB.

No TriggeringPolicy was set for the RollingFileAppender .

The RollingFileAppender must be set up with a TriggeringPolicy . It permits the Appender to know when the rollover must be activated.

To find more information about TriggeringPolicy objects, please read the following javadocs:

Please note that the TimeBasedRollingPolicy is a TriggeringPolicy and and RollingPolicy at the same time.

Missing integer token, that is %i, in FileNamePattern [. ].

The %i conversion token is mandatory for size and time based archiving. In case the %i token is missing, SizeAndTimeBasedFNATP attached to RollingFileAppender will detect the omission and will not start.

No RollingPolicy was set for the RollingFileAppender .

The RollingFileAppender must be set up with a RollingPolicy . It permits the Appender to know what to do when a rollover is requested.

To find more information about RollingPolicy objects, please read the following javadocs:

Please note that the TimeBasedRollingPolicy is a TriggeringPolicy and and RollingPolicy at the same time.

The FileNamePattern property is mandatory for both TimeBasedRollingPolicy and FixedWindowRollingPolicy .

The FileNamePattern property for both TimeBasedRollingPolicy and FixedWindowRollingPolicy is mandatory.

Please refer to the documentation of TimeBasedRollingPolicy and FixedWindowRollingPolicy for examples.

The File property must be set before any rolling policy or triggering policy.

The File property, if present, must be placed before any rolling policy or triggering policy. Thus, in a configuration file, the File property, if present, must be declared before any rolling policy or triggering policy declarations.

File property collides with fileNamePattern . Aborting.

When the file property matches the regular expression defined by fileNamePattern , there is a risk of collision. A collision occurs when the active log file as defined by the file property has the same path as an existing log archive. Such a collision will result in the log archive being overwritten.

As such, in case file property matches the regular expression defined by fileNamePattern , in order to avoid data loss, RollingFileAppender will emit an error message and refuse to start.

The date format in fileNamePattern will result in collisions in the names of archived log files.

This error message is output when the date time pattern in the %d token within the fileNamePattern is not collision free. For example, the following code>fileNamePattern will result in the same log archive every day of the week after the first week of the month.

As such collisions will result in log data loss, RollingFileAppender will check for a variety of such possible collisions and will not start if any collisions are detected.

File / FileNamePattern option has the same value «. » as that given for appender [. ] defined earlier.

If a FileAppender / RollingFileAppender defined earlier has the same File option as the current appender, then those two appenders are in collision as FileAppender instances cannot share the same output target. To prevent loss of data, the current appender will not start. Make sure that each appender has a unique File option.

By analogy the same restriction applies to the FileNamePattern option of RollingFileAppender. Make sure that each RollingFileAppender has a unique FileNamePattern option

Failed to rename file [x] as [y].

On the Windows platform a log file cannot be renamed if there are handles referencing it. For example, when the file is read by another process such as less , tail , etc. During application hot-redeployment, the old instance of the application will have open references to log files until the old instance is completely shutdown or until the stop() method on its LoggerContext is invoked.

Process Explorer can help you locate the processes which reference a given file (Find -> Find Handle or DLL). On Linux, you can use the lsof pathToFile command to find which process has the file given by pathToFile open.

Rolling might also fail due to incorrect file permission settings. On Windows, renaming a file requires the «modify» permission which is different than the permission to «write» to the file.

File rename operations during rollover can be avoided altogether by omitting the file property in RollingFileAppender.

In practice, it can be hard to set the right permissions or to ensure that there are no file handle references to log files.

Under many circumstances, it can be more robust to avoid file renaming during rollover altogether. This is as easy as omitting the file property in RollingFileAppender , as shown in the next configuration snippet.

Note that for FixedWindowRollingPolicy , the file property is mandatory.

On Unix-*

On the Unix platform, the basic/quick rename method supplied by the JDK does not work if the source and target files are located on different file systems. In order to deal with this contingency, logback will resort to renaming by copying if all of the following three conditions are met:

1. quick renaming fails,
2. source and destination files for the rename are on different file systems,
3. the host JVM platform runs Java 7 or later.

The code for determining the file system of a file requires Java 7. No rename by copying will be performed on Java 6 or earlier.

As explained in the Windows section above, renaming can be avoided altogether by omitting the file property.

The File property must be set before FixedWindowRollingPolicy

The File property is mandatory with FixedWindowRollingPolicy . Moreover, the File option must be set before the FixedWindowRollingPolicy element.

Refer to the logback manual on FixedWindowRollingPolicy for more information.

Nested element within , or elements is disallowed

For example, the following is considered incorrect.

However, it can be written with the desired effect as follows.

We are of the opinion that nested-if form can always be transfomed into the surrounding-if form.

Prudent mode is not supported with FixedWindowRollingPolicy .

Given that FixedWindowRollingPolicy performs multiple file rename operations during roll over, and that these operations cannot be guaranteed to be safe in a multi-JVM context, prudent mode is not allowed in conjunction with a FixedWindowRollingPolicy .

SyslogAppender does not admit a layout.

Given that the format of a syslog request follows strict rules, you cannot freely specify the layout to be used with SyslogAppender. However, you can use SuffixPattern option instead to influence the contents of the message sent to the syslog daemon.

For more information on SyslogAppender please refer to the its documentation.

Only and only one appender can be nested the element in SiftingAppender .

SiftingAppender admits one and only one nested appender.

Could not find Janino library on the class path. Skipping conditional processing.

Conditional processing in configuration files requires the Janino library. See the setup instructions for adding Janino to your class path.

As of logback version 0.9.28, JaninoEventEvaluator expects Java blocks.

As of logback version 0.9.28, JaninoEvaluator expects Java «block», i.e. the body of a method. In previous versions only boolean expressions were allowed. For backward compatibility reasons, whenever logback sees a boolean expression it will attempt to convert it to a block by prefixing the expression with «return» and suffixing it with a semicolon.

Boolean expressions can quickly become hairy. For example, the following boolean expression is rather difficult to grok.

whereas as its Java block equivalent is considerably easier to follow.

element is deprecated in favor of a more direct syntax.

Instead of writing (DEPRECATED)

prefer the direct form (GOOD)

In a conversion pattern, opened parenthesis must be closed.

In conversion patterns, parentheses are special because they are treated as grouping tokens. If a parenthesis character needs to be viewed as a literal, it needs to be escaped by preceding each parenthesis with a backslash. As in, (%d [%thread]) .

Error during SAX parser configuration

If you see the following error is thrown during logback configuration

then we suggest that you specify a SAX parser that supports selective feature enabling/disabling. Try setting the following system property.

Appenders must be defined before they are referenced.

The restriction described below has been lifted in logback version 1.3. The description is kept for users of logback 1.2 and earlier.

In a configuration file, at the point where an appender is referenced by name, it must be defined earlier in the configuration file. Referencing an appender defined later in the file is not allowed. Below are examples of correct and incorrect order of definition and reference.

Below is an example of a correct ordering, where appender definition precedes references made to it.

Below is an example of an incorrect ordering, where appender definition follows references made to it.

Источник

Помоги компилятору помочь тебе

Предисловие

Современные компиляторы обладают огромным количеством диагностик. И удивительно, что очень малая их часть включена по умолчанию.

Огромное количество претензий, которые предъявляют к языку C++ в этих ваших интернетах, — про сложность, небезопасность, стрельбу по ногам и т.п., — относятся как раз к тем случаям, когда люди просто не знают о том, что можно решить эти проблемы лёгким движением пальцев по клавиатуре.

Давайте же исправим эту вопиющую несправедливость, и прольём свет истины на возможности компилятора по предотвращению ошибок.

Содержание

Ода компилятору

Компилятор – лучший друг плюсовика. Компилятор — это не просто транслятор формального человекочитаемого языка в машинные коды. Компилятор — лучший помощник в написании программ.

Важная (и не единственная) помощь, которую оказывает компилятор — поиск ошибок. И я говорю не об опечатках, несовпадении типов и прочих синтаксических ошибках. Я говорю об огромном наборе ошибок, которые можно выловить с помощью механизма предупреждений.

Часто встречаю мнение о том, что предупреждений слишком много, они дают ложноположительные результаты, мешают работать, замыливают глаз, отвлекают от «настоящих» ошибок и т.п. Такое действительно бывает, но это большая редкость.

Игнорировать нельзя исправить

Большинство предупреждений — это не «бзик» компилятора, который можно просто проигнорировать. Предупреждение — это потенциальная ошибка. Предупреждение — это сигнал от компилятора о том, что написано одно, а требуется, возможно, что-то совершенно иное.

Поэтому программист должен помочь компилятору понять, как трактовать спорную ситуацию. То есть либо поправить свою ошибку, либо сообщить компилятору явно о том, что нужно верить программисту и делать именно то, что написано. Причём это поможет не только компилятору, но и человеку, который будет читать код. Лишний static_cast или пара скобок будут явно свидетельствовать о том, что имелось в виду именно то, что написано.

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

Надеюсь, что данное не слишком занимательное чтиво поможет правильно поставить запятую в заголовке этого раздела.

Сразу хочу оговориться, что далее речь пойдёт исключительно о языке C++ и компиляторе GCC (впрочем, подавляющая часть информации актуальна и для компилятора Clang). Информацию о других компиляторах и языках придётся искать в соответствующих справочниках.

-Wall — это «агрегатор» базовых предупреждений. В языке C++ он включает в себя длинный перечень предупреждений, каждое из которых будет рассмотрено отдельно (на самом деле, рассмотрены будут не все, а только те, которые непосредственно помогают выявлять ошибки).

Несмотря на название, этот флаг включает далеко не все предупреждения, которые умеет обнаруживать компилятор.

-Waddress

Предупреждает о странной работе с адресами. Например, об использовании адреса функции в условном выражении. Такое может произойти, если забыть поставить скобки после имени функции:

Также этот флаг может спасти от типичной ошибки новичка — сравнения строкового литерала с адресом. Очевидно, программист хотел сравнить строки, но в результате сравнил два указателя:

-Warray-bounds=1

Предупреждает о выходе за пределы массивов. Используется только вместе с -O2 .

-Wbool-compare

Предупреждает о сравнении булева выражения с целым числом, которое нельзя трактовать как булево:

-Wbool-operation

Предупреждает о подозрительных операциях с булевыми выражениями. Например, о побитовом отрицании:

Что касается инкрементов и декрементов булевых переменных, то в C++17 это просто ошибки, безо всяких предупреждений.

-Wcatch-value

Предупреждает о обработчиках исключений, которые принимают полиморфные объекты по значению:

Есть и более сильные версии предупреждения: -Wcatch-value=n (см. справку к компилятору).

-Wchar-subscripts

Предупреждает об обращении к массиву по индексу, тип которого char . А ведь char является знаковым на многих машинах:

Предупреждает о наличии последовательности, начинающей новый комментарий ( /* ), внутри многострочного комментария, либо о разрыве строки при помощи обратного слеша внутри однострочного комментария.

-Wint-in-bool-context

Предупреждает о подозрительном использовании целых чисел там, где ожидаются булевы выражения, например, в условных выражениях:

Другой пример — операции побитового сдвига в булевом контексте. Вполне вероятно, что здесь произошла опечатка, и имелся в виду не сдвиг, а сравнение:

А также сообщает о любых видах умножения в булевом контексте.

-Winit-self

Предупреждает об инициализации переменных самими сабями. Используется только вместе с флагом -Wuninitialized .

-Wlogical-not-parentheses

Предупреждает об использовании логического отрицания в левой части сравнения. При этом если правая часть сравнения является сама по себе булевым выражением, то предупреждения не будет.

Используется для того, чтобы отлавливать подозрительные конструкции вроде следующей:

Традиционный способ сообщить компилятору, что так и было задумано — поставить скобки, о чём и сообщает компилятор.

-Wmaybe-uninitialized

Предупреждает о том, что существует возможность использования непроинициализированной переменной.

В данном конкретном случае решается с помощью конструкции default :

-Wmemset-elt-size

Предупреждает о подозрительных вызовах функции memset , когда первый аргумент — это массив, а третий аргумент — количество элементов в массиве, но не количество байт, занимаемой этим массивом в памяти.

-Wmemset-transposed-args

Предупреждает о том, что пользователь, вероятно, перепутал порядок аргументов в функции memset :

-Wmisleading-indentation

Предупреждает о том, что отступы в коде не отражают структуру этого кода. Особенно это актуально для конструкций if , else , while и for . Пример:

-Wmissing-attributes

Предупреждает о ситуации, когда специализация шаблона объявлена не с тем же списком атрибутов, что и оригинальный шаблон.

-Wmultistatement-macros

Предупреждает о макросах, состоящих из нескольких инструкций, и используемых в выражениях if , else , while и for . В такой ситуации под действие выражений попадает только первая инструкция макроса, и это, вероятно, ошибка:

-Wnonnull

Предупреждает о передаче нулевого указателя в функцию, аргументы которой помечены атрибутом nonnull .

-Wnonnull-compare

Предупреждает о сравнении с нулём аргумента функции, помеченного атрибутом nonnull .

-Wparentheses

Типичный случай — опечатались, и вместо равенства написали присвоение:

Компилятор, естественно, сомневается:

Либо исправляем код, либо убеждаем компилятор в том, что мы хотели именно присвоение:

-Wpessimizing-move

Иногда явная попытка переноса может ухудшить производительность. Пример:

-Wreorder

Предупреждает о том, что порядок инициализации членов класса не соответствует порядку их объявления. Поскольку компилятор может переупорядочить инициализацию этих членов, результат может быть неочевидным.

-Wreturn-type

Предупреждает о том, что из функции не вернули заявленный результат:

-Wsequence-point

Сообщает о подозрительных операциях относительно точек следования. Любимый пример (никогда так не делайте):

-Wsign-compare

Одно из важнейших предупреждений. Сообщает о сравнении знаковых и беззнаковых чисел, которое может произвести некорректный результат из-за неявных преобразований. К примеру, отрицательное знаковое число неявно приводится к беззнаковому и внезапно становится положительным:

-Wsizeof-pointer-div

Предупреждает о подозрительном делении друг на друга двух результатов выражения sizeof , когда размер указателя делится на размер объекта. Обычно это бывает, когда пытаются вычислить размер массива, но вместо массива по ошибке берут указатель:

-Wsizeof-pointer-memaccess

Предупреждает о подозрительных параметрах, передаваемых в строковые функции и функции для работы с памятью ( str. , mem. и т.п.), и использующих оператор sizeof . Например:

-Wstrict-aliasing

Каламбур типизации (strict aliasing) — это отдельная большая тема для разговора. Предлагаю читателю найти литературу по этой теме самостоятельно.

В общем, это тоже крайне полезное предупреждение.

-Wswitch

Предупреждает о том, что не все элементы перечисления задействованы в конструкции switch :

-Wtautological-compare

Предупреждает о бессмысленном сравнении переменной с самой собой:

Кроме того, сообщает о сравнениях при участии битовых операций, которые имеют всегда один и тот же результат (всегда истинно или всегда ложно):

-Wtrigraphs

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

-Wuninitialized

Предупреждает об использовании переменных и членов класса, которые не были проинициализированы:

-Wunused-function

Предупреждает о том, что статическая функция объявлена, но не определена, либо о том, что статическая функция, не помеченная как inline , не используется.

-Wunused-variable

Предупреждает о том, что переменная не используется.

Для того, чтобы помочь компилятору понять, что так и задумывалось, можно использовать конструкцию static_cast (. ) :

«Агрегатор» дополнительных предупреждений. Включает много интересного, чего нет в -Wall (как и в случае с -Wall , рассмотрены будут не все возможности).

-Wempty-body

Предупреждает о пустом теле условных выражений или цикла do-while . Чаще всего это говорит об опечатке, меняющей логику программы:

-Wimplicit-fallthrough

Предупреждает о «проваливании» в операторе switch :

Компилятор предполагает, что программист забыл break , и case 2 не должен проваливаться:

В C++17 для обозначения явного намерения появился специальный атрибут — fallthrough :

-Wmissing-field-initializers

Предупреждает о том, что отдельные члены структуры не были проинициализированы. Скорее всего это просто забыли сделать:

-Wredundant-move

Предупреждает о ненужном вызове std::move в случаях, когда компилятор сам сделает всё, что нужно:

-Wtype-limits

Предупреждает о сравнениях, которые всегда имеют один и тот же результат. Например, когда беззнаковое число проверяется на неотрицательность. Если программист делает такую проверку, то, видимо, предполагает, что число в теории может быть отрицательным, однако, это не так. Видимо, он где-то ошибся:

-Wshift-negative-value

Предупреждает об операциях сдвига для отрицательных значений. Отрицательными могут быть только знаковые числа, а для них это некорректно:

-Wunused-parameter

Предупреждает о неиспользуемом параметре функции. Возможно, про него просто забыли, и в этом случае функция может работать некорректно.

В C++17 для явного выражения намерения существует атрибут maybe_unused :

-Wunused-but-set-parameter

Предупреждает о том, что в параметр функции было записано значение, но после этого он ни разу не использовался. Возможно, про него снова забыли:

-Wpedantic

-Wall и -Wextra — это не всё, на что способен компилятор.

В дополнение к ним существует флаг -Wpedantic (он же -pedantic ), который проверяет соответствие кода стандарту ISO C++, сообщает об использовании запрещённых расширений, о наличии лишних точек с запятой, нехватке переноса строки в конце файла и прочих полезных штуках.

Нужно больше предупреждений

Но и это ещё не всё. Есть несколько флагов, которые почему-то не входят ни в один из «аргегаторов», но крайне важны и полезны.

-Wctor-dtor-privacy

Предупреждает о том, что класс выглядит неиспользуемым, потому что конструкторы и деструкторы закрыты, а друзей и открытых статических функций-членов у него нет.

Аналогично, сообщает, что у класса есть закрытые функции-члены, а открытых нет ни одной.

-Wnon-virtual-dtor

Предупреждает о том, что у класса есть виртуальные функции-члены, но деструктор при этом не виртуальный. Очень сложно представить себе такой класс. Вероятнее всего, это ошибка.

-Wold-style-cast

Предупреждает о приведении типов в стиле языка C. В плюсах есть прекрасные и ужасные static_cast , dynamic_cast , reinterpret_cast и const_cast , которые более локальны и более описательны. Сишный способ слишком сильный и — о, ужас, — небезопасный. Лучше его не использовать вообще.

-Woverloaded-virtual

Предупреждает о попытке в классе-наследнике перегрузить виртуальную функцию базового класса:

-Wsign-promo

Крайне полезный флаг. Предупреждает о неочевидном выборе перегруженной функции:

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

-Wduplicated-branches

Предупреждает о том, что ветви if и else одинаковы:

Условный оператор ?: также под прицелом:

Для меня абсолютная загадка, почему этот флаг не включён не то, что в -Wall , а вообще по умолчанию.

-Wduplicated-cond

Предупреждает об одинаковых условиях в цепочках if-else-if :

-Wfloat-equal

Предупреждает о проверке на равенство между двумя числами с плавающей точкой. Скорее всего, это ошибка, и сравнение нужно проводить с заданной точностью.

Если же требуется именно сравнить на равенство (такое редко, но бывает), то можно использовать std::equal_to , который под предупреждение не попадает.

-Wshadow=compatible-local

Полезная опция, которая не даёт перекрыть локальную переменную другой локальной переменной при условии, что они имеют совместимые типы.

-Wcast-qual

Предупреждает о преобразовании указателя, при котором сбрасываются квалификаторы. Например, чтобы случайно не потерять const .

-Wconversion

Очень, очень, очень важный флаг. Он предупреждает об огромном количестве неявных сужающих (то есть потенциально приводящих к потере информации) преобразований, которые могут быть следствием ошибки программиста. Например:

Если вы раньше никогда не включали этот флаг, то будет интересно.

-Wzero-as-null-pointer-constant

Предупреждает об использовании целочисленного нуля вместо nullptr .

Флаг для педантов. Сообщает о лишней точке с запятой после определения функции-члена.

-Wsign-conversion

Как и -Wconversion помогает предотвратить большое количество неявных преобразований, которые запросто могут быть ошибками:

-Wlogical-op

Предупреждает о подозрительных логических выражениях. Например, когда вместо побитового «И» поставили логическое «И», или логическое выражение имеет одинаковые операнды:

-Werror

С этого, вообще говоря, стоило бы начать. Данный флаг делает все предупреждения ошибками. Код не скомпилируется при наличии хотя бы одного предупреждения.

Без этого флага всё остальное имеет мало смысла. Но если понять и принять мысль о том, что предупреждение — это что-то подозрительное, и их быть не должно, то именно этот флаг и позволит поддерживать код в чистоте.

В дополнение к -Werror существует флаг -pedantic-errors , который не эквивалентен комбинации -Wpedantic -Werror .

Заключение

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

Да, такой список флагов может породить большое количество ошибок, которые поначалу могут показаться излишними. Но явное лучше неявного. Если знаешь, что делаешь — делай. Но делай это так, чтобы всем было понятно, что именно так ты и хотел. Поработав таким образом хотя бы неделю, вы поймёте, насколько это прекрасно, и уже не сможете вернуться обратно.

Любите ваш компилятор и помогайте ему помогать вам писать программы.

Источник