Что такое код lstrcat


Содержание

Описание функций языка Си

All | _ | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

strcat – объединение строк.

#include
char *strcat (char *destination, const char *append);

destination – указатель на массив в который будет добавлена строка.
append – указатель на массив из которого будет скопирована строка.

Функция возвращает указатель на массив, в который добавлена строка (destination).

Функция strcat добавляет в строку, на которую указывает аргумент destination, строку, на которую указывает аргумент append. Символ конца строки помещается в конце объединенных строк.

Если строки перекрываются, результат объединения будет не определен.

В примере объединяется строка «первая строка» со строкой «вторая строка» с помощью функции strcat

Функции обработки строк в Cи

В программе строки могут определяться следующим образом:

  • как строковые константы;
  • как массивы символов;
  • через указатель на символьный тип;
  • как массивы строк.

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

Любая последовательность символов, заключенная в двойные кавычки «» , рассматривается как строковая константа .

Для корректного вывода любая строка должна заканчиваться нуль-символом ‘\0’ , целочисленное значение которого равно 0. При объявлении строковой константы нуль-символ добавляется к ней автоматически. Так, последовательность символов, представляющая собой строковую константу, будет размещена в оперативной памяти компьютера, включая нулевой байт.

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

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

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

При определении массива символов необходимо сообщить компилятору требуемый размер памяти.

Компилятор также может самостоятельно определить размер массива символов, если инициализация массива задана при объявлении строковой константой:

В этом случае имена m2 и m3 являются указателями на первые элементы массивов:

  • m2 эквивалентно &m2[0]
  • m2[0] эквивалентно ‘Г’
  • m2[1] эквивалентно ‘o’
  • m3 эквивалентно &m3[0]
  • m3[2] эквивалентно ‘x’

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

Для задания строки можно использовать указатель на символьный тип .

В этом случае объявление массива переменной m4 может быть присвоен адрес массива:

Здесь m3 является константой-указателем. Нельзя изменить m3 , так как это означало бы изменение положения (адреса) массива в памяти, в отличие от m4 .

Для указателя можно использовать операцию увеличения (перемещения на следующий символ):

Массивы символьных строк

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

В этом случае poet является массивом, состоящим из четырех указателей на символьные строки. Каждая строка символов представляет собой символьный массив, поэтому имеется четыре указателя на массивы. Указатель poet[0] ссылается на первую строку:
*poet[0] эквивалентно ‘П’,
*poet[l] эквивалентно ‘-‘.

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

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

strcat_s, wcscat_s, _mbscat_s, _mbscat_s_l strcat_s, wcscat_s, _mbscat_s, _mbscat_s_l

Дополняет строку. Appends a string. Это версии функций strcat, wcscat, _mbscat с усовершенствованной безопасностью, как описано в разделе Функции безопасности в CRT. These versions of strcat, wcscat, _mbscat have security enhancements, as described in Security Features in the CRT.

_mbscat_s и _mbscat_s_l нельзя использовать в приложениях, которые выполняются в среда выполнения Windows. _mbscat_s and _mbscat_s_l cannot be used in applications that execute in the Windows Runtime. Дополнительные сведения: Функции CRT, которые не поддерживаются в приложениях универсальной платформы Windows. For more information, see CRT functions not supported in Universal Windows Platform apps.

Синтаксис Syntax

Параметры Parameters

стрдестинатион strDestination
Строковый буфер назначения, завершающийся символом NULL. Null-terminated destination string buffer.

numberOfElements numberOfElements
Размер строкового буфера назначения. Size of the destination string buffer.

стрсаурце strSource
Исходная строка, завершающаяся нулем. Null-terminated source string buffer.

locale locale
Используемый языковой стандарт. Locale to use.

Возвращаемое значение Return Value

Возвращает нуль в случае успеха или код ошибки в случае неудачи. Zero if successful; an error code on failure.

Условия ошибок Error Conditions

стрдестинатион strDestination numberOfElements numberOfElements стрсаурце strSource Возвращаемое значение Return value Содержимое стрдестинатион Contents of strDestination
Null или без завершения NULL or unterminated Любое действие any Любое действие any EINVAL EINVAL не изменено not modified
Любое действие any Любое действие any NULL NULL EINVAL EINVAL стрдестинатион[0] имеет значение 0 strDestination[0] set to 0
Любое действие any 0 или слишком мал 0, or too small Любое действие any ERANGE ERANGE стрдестинатион[0] имеет значение 0 strDestination[0] set to 0

Заметки Remarks

Функция strcat_s добавляет стрсаурце в стрдестинатион и завершает результирующую строку символом NULL. The strcat_s function appends strSource to strDestination and terminates the resulting string with a null character. Начальный символ стрсаурце перезаписывает завершающий нуль символ стрдестинатион. The initial character of strSource overwrites the terminating null character of strDestination. Поведение strcat_s не определено, если исходная и Целевая строки перекрываются. The behavior of strcat_s is undefined if the source and destination strings overlap.

Обратите внимание, что второй параметр — это общий размер буфера, а не оставшийся размер: Note that the second parameter is the total size of the buffer, not the remaining size:

wcscat_s и _mbscat_s — это версии strcat_sдля расширенных символов и многобайтовых символов. wcscat_s and _mbscat_s are wide-character and multibyte-character versions of strcat_s. Аргументы и возвращаемое значение wcscat_s являются строками расширенных символов. _mbscat_s являются строками многобайтовых символов. The arguments and return value of wcscat_s are wide-character strings; those of _mbscat_s are multibyte-character strings. В остальном эти три функции ведут себя идентично. These three functions behave identically otherwise.

Если стрдестинатион является пустым указателем или не завершается нулем или если стрсаурце является пустым указателем или если строка назначения слишком мала, вызывается обработчик недопустимых параметров, как описано в разделе Проверка параметров. If strDestination is a null pointer, or is not null-terminated, or if strSource is a NULL pointer, or if the destination string is too small, the invalid parameter handler is invoked, as described in Parameter Validation. Если выполнение может быть продолжено, эти функции возвращают еинвал и применяют значение « еинвал«. If execution is allowed to continue, these functions return EINVAL and set errno to EINVAL.

Версии функций с суффиксом _l имеют одинаковое поведение, но используют переданный параметр языкового стандарта вместо текущего языкового стандарта. The versions of functions that have the _l suffix have the same behavior, but use the locale parameter that’s passed in instead of the current locale. Дополнительные сведения см. в разделе Locale. For more information, see Locale.

В C++ использование данных функций упрощено наличием шаблонных перегрузок; перегруженные методы могут автоматически определять длину буфера (что исключает необходимость указания аргумента с размером буфера), а также они могут автоматически заменять более старые, незащищенные функции их новыми безопасными аналогами. In C++, using these functions is simplified by template overloads; the overloads can infer buffer length automatically (eliminating the need to specify a size argument) and they can automatically replace older, non-secure functions with their newer, secure counterparts. Дополнительные сведения см. в разделе Безопасные перегрузки шаблонов. For more information, see Secure Template Overloads.

Версии отладочной библиотеки этих функций сначала заполняют буфер 0xFE. The debug library versions of these functions first fill the buffer with 0xFE. Чтобы отключить это поведение, используйте _CrtSetDebugFillThreshold. To disable this behavior, use _CrtSetDebugFillThreshold.

Сопоставления подпрограмм обработки обычного текста Generic-Text Routine Mappings

Подпрограмма TCHAR.H TCHAR.H routine _UNICODE и _MBCS не определены _UNICODE & _MBCS not defined _MBCS определено _MBCS defined _UNICODE определено _UNICODE defined
_tcscat_s _tcscat_s strcat_s strcat_s _mbscat_s _mbscat_s wcscat_s wcscat_s

Требования Requirements

Подпрограмма Routine Обязательный заголовок Required header
strcat_s strcat_s
wcscat_s wcscat_s или or
_mbscat_s _mbscat_s

Дополнительные сведения о совместимости см. в разделе Compatibility. For additional compatibility information, see Compatibility.

Что такое строка кода?

Я понимаю, что нет однозначно «правильного» ответа на этот вопрос, но когда люди говорят о строках кода, что они имеют в виду? Например, в C ++ вы считаете пустые строки? Комментарии? линии с открытой или закрытой скобкой?

Я знаю, что некоторые люди используют LoC в качестве меры производительности, и мне интересно, существует ли здесь стандартное соглашение. Кроме того, я думаю, что есть способ заставить различные компиляторы считать строки кода — есть ли там стандартное соглашение?

20 ответов

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

Это может заставить вас спросить: «Почему тогда я буду использовать LOC в качестве меры производительности?» и ответ таков: потому что на самом деле не имеет значения, как вы считаете строку кода, если вы считаете их последовательно, вы можете получить представление об общем размере проекта по отношению к другим.

Взгляните на статью из Википедии , особенно раздел » Измерение SLOC «:

Существует два основных типа мер SLOC: физический SLOC и логический SLOC. Конкретные определения этих двух показателей различаются, но наиболее распространенное определение физического SLOC — это количество строк в тексте исходного кода программы, включая строки комментариев. Пустые строки также включены, если только строки кода в разделе не содержат более 25% пустых строк. В этом случае пустые строки, превышающие 25%, не учитываются в строках кода.

Логические меры SLOC пытаются измерить количество «операторов», но их конкретные определения привязаны к конкретным компьютерным языкам (одна простая логическая мера SLOC для C-подобных языков программирования — это число точек с запятой в конце оператора). Гораздо проще создавать инструменты для измерения физического SLOC, а физические определения SLOC легче объяснить. Однако физические меры SLOC чувствительны к логически нерелевантным соглашениям о форматировании и стилях, в то время как логические SLOC менее чувствительны к соглашениям о форматировании и стилях. К сожалению, меры SLOC часто указываются без их определения, и логический SLOC часто может существенно отличаться от физического SLOC.

Рассмотрим этот фрагмент кода на C как пример неоднозначности, возникшей при определении SLOC:

В этом примере мы имеем:

  • 1 Физические строки кода LOC
  • 2 логические строки кода lLOC (для выписки и выписки printf)
  • 1 строка комментария
  • количество комментариев
  • количество пустых строк, потому что они важны для читабельности, но не более, чем одна
  • строки с фигурными скобками тоже учитываются, но применяются те же правила, что и для пустых строк — т.е. 5 вложенных фигурных скобок без кода между ними считаются одной строкой.

Я также смиренно предположил бы, что любой показатель производительности, который на самом деле зависит от значения LoC, является двухъярусным

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

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

Все, что «wc -l» возвращает, является моим номером.

Если вы используете LOC в качестве меры производительности, вы внезапно обнаружите, что ваши программисты гораздо более многословно пишут «игра в систему». Это глупая мера, и только глупые люди используют ее для чего-то большего, чем просто хвастовство.

«Строки кода» должны включать все, что вы должны поддерживать. Это включает в себя комментарии, но исключает пробелы.

Если вы используете это как показатель производительности, убедитесь, что вы делаете разумные сравнения. Строка C ++ отличается от строки Ruby.

1 строка = 4 секунды чтения. Если требуется больше, чем это, чтобы понять, что я говорю по этой строке, строка слишком длинная.

LOC — заведомо неоднозначная метрика. Для подробного сравнения он действителен только при сравнении кода, написанного на том же языке, с тем же стилем, той же командой.

Тем не менее, он обеспечивает определенное понятие сложности, когда рассматривается в представлении о порядке величины. Программа на 10000 строк намного сложнее, чем программа на 100 строк.

Преимущество LOC заключается в том, что wc -l возвращает его, и в отличие от многих других программных метрик, в его понимании или расчете нет никакой изощренности.

Там нет правильного ответа.

Для неофициальных оценок я использую wc -l.

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

Если бы я делал это в Scheme или Lisp, я бы посчитал выражения.


Как уже говорили другие, самое главное, чтобы ваш счет был последовательным. Также важно, для чего вы это используете. Если вы просто хотите, чтобы потенциальный новый сотрудник знал, насколько велик ваш проект, используйте wc -l. Если вы хотите заняться планированием и оценкой, возможно, вы захотите стать более формальными. Вы не должны ни при каких обстоятельствах использовать LOC для расчета компенсации программисту.

Вы должны думать о « потраченных строках кода», а не о «произведенных строках кода».

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

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

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

Понятие LOC — это попытка количественно определить объем кода. Как указывалось в других ответах, не имеет значения, что вы конкретно называете строкой кода, если вы последовательны. Интуитивно кажется, что программа из 10 строк меньше, чем программа из 100 строк, которая меньше, чем программа из 1000 строк и так далее. Вы можете ожидать, что для создания, удаления и поддержки 100-строчной программы требуется меньше времени, чем для 1000-строчной. Неформально, по крайней мере, вы можете использовать LOC, чтобы получить приблизительное представление о количестве работы, необходимой для создания, отладки и поддержки программы определенного размера.

Конечно, есть места, где это не держится. Например, сложный алгоритм, отображаемый в 1000 строк, может быть намного сложнее разработать, чем, скажем, простая программа базы данных, которая потребляет 2500 строк.

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

  1. LOCphy: физически линии
  2. LOCbl: Пустые строки Комментарблоки werden als Kommentarzeile gezählt
  3. LOCpro: строки программирования (объявления, определения, директивы и код)
  4. LOCcom: строки комментариев

Многие доступные инструменты дают информацию о проценте заполненных строк и так далее.

Нужно просто посмотреть на это, но не только рассчитывать на это.

LOC сильно растет на старте проекта и часто уменьшается после обзоров;)

Я думаю об этом как о едином обрабатываемом утверждении. Например

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

Я согласен с принятым ответом Крейга Н, однако я хотел бы добавить, что в школе меня учили, что пробелы, комментарии и объявления не должны рассматриваться как «строки кода» с точки зрения измерения строк кода производится программистом в целях повышения производительности, то есть по старому правилу «15 строк в день».

Я использую wc -l для быстрой оценки сложности рабочего пространства. Тем не менее, как показатель производительности LOC является худшим . Я вообще считаю, что это очень продуктивный день, если мой, если LOC счетчик идет вниз.

Я знаю, что некоторые люди используют LoC в качестве меры производительности

Не могли бы вы сказать мне, кто они, чтобы я не работал с ними (или, что еще хуже, с ними)?

Если я могу реализовать в 1400 строк, используя Haskell, то, что я мог бы реализовать в 2800 строк, используя C, я более продуктивен в C или Haskell? Что займет больше времени? Какие из них будут иметь больше ошибок (подсказка: это линейно по количеству LOC)?

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

При этом, как вы считаете, LOCs? Просто используйте wc -l . Почему это правильный инструмент? Что ж, вы, вероятно, не заботитесь о каком-то конкретном числе, но об общих общих тенденциях (повышение или понижение и насколько), об отдельных тенденциях (повышение или понижение, смена направления, как быстро, . ) и о почти все, кроме числа 82 763.

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

Посчитайте, сколько раз встречается ‘\n’ . Другими интересными символами могут быть ‘;’ , ‘<' и '/' .

В мире .NET, похоже, существует глобальное соглашение о том, что строка кода (LoC) является точкой последовательности отладки . Точка последовательности — это единица отладки, это часть кода, выделенная темно-красным цветом при установке точки останова. С точкой последовательности мы можем говорить о логическом LoC , и эту метрику можно сравнить по различным языкам .NET. Метрика логического кода LoC поддерживается большинством инструментов .NET, включая метрику кода VisualStudio, NDepend или NCover.

Метод 8 LoC (точки последовательности в начальных и конечных скобках не учитываются):

В отличие от физического LoC (имеется в виду просто подсчет количества строк в исходном файле), логический LoC имеет огромное преимущество — он не зависит от стиля кодирования. Мы все согласны с тем, что стиль кодирования может варьировать физический подсчет LoC на порядок от одного разработчика к другому. Я написал более подробный пост в блоге на эту тему: Как вы подсчитываете количество строк кода (LOC)?

Использование LOC для измерения производительности программиста похоже на оценку качества картины по ее размеру. Насколько я понимаю, единственная «ценность» LOC — это произвести впечатление на ваших клиентов и напугать ваших конкурентов.

Тем не менее, я думаю, что количество скомпилированных инструкций будет наименее неоднозначным. Тем не менее, плохие программисты имеют преимущество в том, что они, как правило, пишут излишне подробный код. Я помню, как однажды заменил 800+ строк действительно плохого кода на 28 строк. Это делает меня бездельником?

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

Документирование кода в Python. PEP 257

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

PEP 257 описывает соглашения, связанные со строками документации python, рассказывает о том, как нужно документировать python код.

Цель этого PEP — стандартизировать структуру строк документации: что они должны в себя включать, и как это написать (не касаясь вопроса синтаксиса строк документации). Этот PEP описывает соглашения, а не правила или синтаксис.

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

Что такое строки документации?

Строки документации — строковые литералы, которые являются первым оператором в модуле, функции, классе или определении метода. Такая строка документации становится специальным атрибутом __doc__ этого объекта.

Все модули должны, как правило, иметь строки документации, и все функции и классы, экспортируемые модулем также должны иметь строки документации. Публичные методы (в том числе __init__) также должны иметь строки документации. Пакет модулей может быть документирован в __init__.py.

Для согласованности, всегда используйте «»»triple double quotes»»» для строк документации. Используйте r»»»raw triple double quotes»»», если вы будете использовать обратную косую черту в строке документации.

Существует две формы строк документации: однострочная и многострочная.

Однострочные строки документации

Однострочники предназначены для действительно очевидных случаев. Они должны умещаться на одной строке. Например:

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

Закрывающие кавычки на той же строке. Это смотрится лучше.

Нет пустых строк перед или после документации.

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

Этот тип строк документации подходит только для C функций (таких, как встроенные модули), где интроспекция не представляется возможной. Тем не менее, возвращаемое значение не может быть определено путем интроспекции. Предпочтительный вариант для такой строки документации будет что-то вроде:

(Конечно, «Do X» следует заменить полезным описанием!)

Многострочные строки документации

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

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

Строки документации скрипта (самостоятельной программы) должны быть доступны в качестве «сообщения по использованию», напечатанной, когда программа вызывается с некорректными или отсутствующими аргументами (или, возможно, с опцией «-h», для помощи). Такая строка документации должна документировать функции программы и синтаксис командной строки, переменные окружения и файлы. Сообщение по использованию может быть довольно сложным (несколько экранов) и должно быть достаточным для нового пользователя для использования программы должным образом, а также полный справочник со всеми вариантами и аргументами для искушенного пользователя.

Строки документации модуля должны, как правило, перечислять классы, исключения, функции (и любые другие объекты), которые экспортируются модулем, с краткими пояснениями (в одну строчку) каждого из них. (Эти строки, как правило, дают меньше деталей, чем первая строка документации к объекту). Строки документации пакета модулей (т.е. строка документации в __init__.py) также должны включать модули и подпакеты.

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

Строки документации класса обобщают его поведение и перечисляют открытые методы и переменные экземпляра. Если класс предназначен для подклассов, и имеет дополнительный интерфейс для подклассов, этот интерфейс должен быть указан отдельно (в строке документации). Конструктор класса должен быть задокументирован в документации метода __init__. Отдельные методы должны иметь свои строки документации.

Если класс — подкласс другого класса, и его поведение в основном унаследовано от этого класса, строки документации должны отмечать это и обобщить различия. Используйте глагол «override», чтобы указать, что метод подкласса заменяет метод суперкласса и не вызывает его; используйте глагол «extend», чтобы указать, что метод подкласса вызывает метод суперкласса (в дополнение к собственному поведению).

И, напоследок, пример:

А ещё больше примеров можно посмотреть в стандартной библиотеке python (например, в папке Lib вашего интерпретатора python).

Как писать красивый код с PEP 8. Часть #2

«Должен быть один — и желательно только один — очевидный способ сделать это» (с) Дзен Python

Отступ или ведущий пробел чрезвычайно важны в Python. Уровень отступа строк кода в Python определяет, как операторы группируются вместе.

Рассмотрим следующий пример:

Оператор print с отступом позволяет Python знать, что его следует выполнять только в том случае, если оператор if возвращает True. Тот же отступ применяется в Python, чтобы понять какой код выполнять при вызове функции или какой код принадлежит данному классу.

Ключевыми правилами отступления, изложенными в PEP 8, являются:

— Используйте 4 последовательных пробела для обозначения отступа.

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

Табуляция VS Пробелы

Как упоминалось выше, вы должны использовать пробелы вместо табуляции при отступе кода. Вы можете настроить параметры в текстовом редакторе так, чтобы при нажатии клавиши Tab выводилось 4 пробела вместо символа табуляции.

Если вы используете Python 2 и использовали комбинацию табуляции и пробелов для отступа в своем коде, вы не увидите ошибок при попытке его запустить. Чтобы помочь вам проверить согласованность, вы можете добавить флаг -t при запуске кода Python 2 из командной строки. Интерпретатор выдаст предупреждения, если вы не согласны с использованием табуляции и пробелов:

Результат: Непоследовательное использование табуляции и пробелов в отступе

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

Ошибка табуляции: Непоследовательное использование табуляции и пробелов в отступе

Python 3 не позволяет смешивать символы табуляции и пробелы. Поэтому, если вы используете Python 3, эти ошибки выдаются автоматически:

Ошибка табуляции: Непоследовательное использование табуляции и пробелов в отступе

Вы можете написать код Python с помощью табуляции или пробелов, обозначающих отступ. Однако если вы используете Python 3, вы должны соответствовать своему выбору. В противном случае ваш код не будет работать. PEP 8 рекомендует всегда использовать 4 последовательных пробела для обозначения отступа.

Отступ после переноса строки
Когда вы используете продолжения строк, чтобы длина строк не превышала 79 символов, полезно использовать отступы для улучшения читабельности. Это позволяет читателю различать две строки кода и одну строку кода, которая занимает две строки. Есть два стиля отступов, которые вы можете использовать.

Первый из них это выравнивание блока с отступом по открывающему разделителю:

Иногда вы можете обнаружить, что для выравнивания с начальным разделителем требуется всего 4 пробела. Это часто происходит в том случае, если операторы, занимающие несколько строк, такие как if, пробел и открывающая скобка, составляют 4 символа. В этом случае может быть трудно определить, где начинается блок вложенного кода внутри оператора if:

В этом случае PEP 8 предоставляет две альтернативы для улучшения читаемости:

1. Добавьте комментарий после окончательного условия. Из-за подсветки синтаксиса в большинстве редакторов это отделяет условия от вложенного кода:

2. Добавьте дополнительный отступ на продолжение строки:

Альтернативный стиль отступа после переноса строки — висячий отступ. Это типографский термин, означающий, что каждая строка, кроме первой в абзаце или утверждении, имеет отступ. Вы можете использовать висячий отступ для визуального представления продолжения строки кода. Вот пример:

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

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

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


Когда вы пишете код, совместимый с PEP 8, ограничение в 79 символов заставляет вас добавлять разрывы строк в ваш код. Чтобы улучшить читаемость, вы должны сделать отступ для продолжения, чтобы показать, что это продолжение. Есть два способа сделать это. Во-первых, выровнять блок с отступом по открывающему разделителю. Второе — использовать висячий отступ. Вы можете выбрать любой из этих методов отступа в дальнейшей работе.

Где ставить закрывающую скобку

Продолжения строк позволяют разбивать строки внутри круглых, квадратных или фигурных скобках. Забыть о закрывающей скобке очень легко, но важно поместить ее куда-нибудь осмысленно. В противном случае, это может запутать читателя. PEP 8 предоставляет две опции для положения закрывающей скобки в подразумеваемых продолжениях строки:

1. Совместите закрывающую скобку с первым непробельным символом предыдущей строки:

2. Выровняйте закрывающую фигурную скобку с первым символом строки, которая начинает конструкцию:

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

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

Вот несколько ключевых моментов, которые следует помнить при добавлении комментариев в код:

1. Ограничьте длину строки комментариев и строк документации до 72 символов.

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

3. Не забудьте обновить комментарии, если вы измените свой код.

Блок комментариев

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

PEP 8 предусматривает следующие правила для написания комментариев к блоку:

1. Отступ блока комментариев должен быть на том же уровне, что и код, который они описывают.

2. Начните каждую строку с #, за которым следует один пробел.

3. Разделите абзацы строкой, содержащей один #.

Вот блочный комментарий, объясняющий функцию цикла for. Обратите внимание, что предложение переносится на новую строку, чтобы сохранить ограничение в 79 символов:

Иногда, если код очень технический, тогда необходимо использовать более одного абзаца в комментарии блока:

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

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

1. Используйте однострочные комментарии экономно.

2. Напишите однострочный комментарии в той же строке, что и утверждение, к которому они относятся.

3. Отделяйте однострочные комментарии двумя или более пробелами от оператора.

4. Начните встроенные комментарии с # и одного пробела, как блочные комментарии.

5. Не используйте их, чтобы объяснить очевидное.

Ниже приведен пример однострочного комментария:

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

Здесь комментарий дает дополнительную информацию. Однако использование x в качестве имени переменной для ФИО студента является плохой практикой. Такой комментарий не нужен, если вы переименуете переменную:

Наконец, однострочные комментарии, подобные этим, являются плохой практикой, так как они содержат очевидный и беспорядочный код:

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

Докуменирующие строки — это строки, заключенные в двойные (» » «) или одинарные (‘ ‘ ‘) кавычки, которые ставятся в первой строке любой функции, класса, метода или модуля. Вы можете использовать их для объяснения и документирования конкретного блока кода. Существует целый PEP, PEP 257, который охватывает документирующие строки.

Наиболее важные правила, применяемые к этим видам строк:

1. Окружите документирующие строки тремя двойными кавычками с каждой стороны: «»»Это строка документации»»».

2. Напишите их для всех общедоступных модулей, функций, классов и методов.

3. Поместите «»», который завершает многострочную строку документации, на закрывающуюся строку:

Для однострочных строк документации, поставьте «»» на той же строке:

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

Все права принадлежат авторам статьи (команде Real Python).

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

Источник строк кода — Source lines of code

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

содержание

методы измерения

Многие полезные сравнения включают только порядок строк кода в проекте. Использование строк коды для сравнения проекта 10000 линии для проекта 100000 линии является гораздо более полезным , чем при сравнении проекта 20000 линии с проектом на 21000 линии. Хотя это спорно точно , как измерить строки коды, расхождение по порядку величин могут быть четкими показателями сложности программного обеспечения или человеко — часов .

Есть два основных вида мер SLOC: физическое SLOC (LOC) и логический SLOC (Lloc). Конкретные определения этих двух мер различны, но наиболее общее определение физической SLOC является подсчет строк в тексте исходного кода, за исключением строк комментариев программы.

Логическое SLOC попытки измерить количество исполняемого «заявление», но их конкретные определения привязаны к конкретным компьютерным языкам (одна простая логическая SLOC меры для C — подобных языков программирования является числом с запятой заявления оконечного). Гораздо проще создать инструменты , которые измеряют физическую SLOC и физические определения SLOC которые легче объяснить. Однако физические меры SLOC чувствительны к логически неуместные форматирования и стиля конвенции, в то время как логическое SLOC менее чувствителен к форматированию и стилистических конвенций. Однако меры SLOC часто говорится , не давая свое определение и логическое SLOC часто может значительно отличаться от физического SLOC.

Рассмотрим следующий фрагмент кода C в качестве примера неоднозначности столкнулись при определении SLOC:

В этом примере мы имеем:

  • 1 Физическая строка кода (LOC)
  • 2 логических строк кода (Lloc) ( для постановки и PRINTF заявление)
  • 1 строка комментария

В зависимости от программиста и стандарты кодирования, выше «строка кода» может быть написано на многих отдельных строках:

В этом примере мы имеем:

  • 4 Физические строк кода (LOC): это размещение распорки работы должны быть оценены?
  • 2 логических строк кода (Lloc): насчет всей работы писать без выписки строк?
  • 1 строка комментарий: инструменты должны учитывать весь код и комментарии независимо от комментария размещения.

Даже «логический» и «физическое» значение SLOC может иметь большое количество различных определений. Роберт Е. Парк (в то время как в Software Engineering Institute) и другие разработали основы для определения значений SLOC, чтобы дать людям возможность тщательно объяснить и определить меру SLOC, используемый в проекте. Например, большинство систем программного обеспечения повторного использования кода, и определить, какие (если таковые имеются) повторно код для включения важно при составлении отчетов меру.

происхождения

В то время, когда люди начали с помощью SLOC в качестве показателя, наиболее часто используемых языков, таких как FORTRAN и ассемблере , были линейно-ориентированные языки. Эти языки были разработаны в то время , когда перфокарты были основной формой ввода данных для программирования. Один перфокарта обычно представляли одну строку кода. Это был один дискретное объект , который был легко подсчитаны. Он был виден выход программиста , так что имеет смысл для менеджеров подсчета строк кода в качестве измерения производительности программиста, даже имея в виду такие , как « изображений с карты ». На сегодняшний день наиболее часто используемые языки программирования позволяют намного больше возможностей для форматирования. Текстовые строки не больше не ограничены до 80 или 96 столбцов, и одна строка текста уже не обязательно соответствует одной строке кода.

Применение мер SLOC

SLOC мера несколько спорные, особенно в том , что они иногда злоупотребляют. Эксперименты неоднократно подтверждали , что усилие хорошо коррелирует с SLOC, то есть программы с большими значениями SLOC потребуется больше времени для развития. Таким образом, SLOC может быть очень эффективным при оценке усилий. Тем не менее, функциональность менее хорошо коррелирует с SLOC: опытные разработчики могут развивать такую же функциональность с гораздо меньшим количеством кода, так что одна программа с меньшим количеством SLOC может проявлять больше функциональных возможностей, чем другой аналогичной программы. В частности, SLOC является низкая производительность мера индивидов, так как разработчик может развиваться лишь несколько строк и еще гораздо более продуктивным с точки зрения функциональности , чем разработчик , который заканчивает тем , что создает больше линий (и вообще тратить больше усилий). Хорошие разработчики могут объединить несколько программных модулей в единый модуль, совершенствование системы еще появляясь иметь отрицательную производительность , поскольку они удаляют код. Кроме того , особенно опытные разработчики , как правило, назначаются самым сложные задачами, и , таким образом , могут иногда казаться менее «продуктивным» , чем другие разработчики задачи по этому показателю. Кроме того, неопытные разработчики часто прибегают к дублированию кода , который крайне нежелателен , поскольку это более подверженная ошибке и дорого поддерживать, но это приводит к более высокому SLOC.

SLOC особенно неэффективен при сравнении программ , написанных на различных языках , если поправочные коэффициенты не применяются для нормализации языков. Различные языки программирования баланса краткость и ясность по — разному; как крайний пример, большинство языков ассемблера требуют сот строк коды для выполнения тех же задач , как несколько символов в APL . Следующий пример показывает сравнение с программой «привет мир» , написанной в C , и той же программы , написанной на языке COBOL — язык известен тем , что особенно многословен.

С Кобол
Строки кода: 4
(без пробела)
Строки кода: 6
(исключая пробелы)

Еще более распространенная проблема в сравнении SLOC метрики разница между автоматической сгенерированы и рукописной кодой. Современные программные средства часто имеют возможность автоматической генерации огромного количества кода с помощью нескольких щелчков мыши. Например, графические строители пользовательского интерфейса автоматически генерировать весь исходный код для графических элементов управления , просто перетаскивая значок на рабочее пространство. Работа участвует в создании этого кода не может быть разумно сравнить с работой , необходимой для написания драйвера устройства, например. К тому же, ручной закодированы пользовательский класс GUI легко может быть более сложным , чем простой драйвер устройства; следовательно, недостаток этой метрики.

Есть несколько моделей , стоимость, график и оценки усилий , которые используют SLOC в качестве входного параметра, в том числе широко используются Конструктивная Стоимость модель ( COCOMO серии) моделей по Барри Сет и др., ЦЕНА Systems Истинного S и Galorath в ГЭЭ-SEM . В то время как эти модели показали хорошую прогностическую силу, они только столь же хороши , как и оценки ( в частности сметы SLOC) , подаваемых на них. Многие из них выступают за использование функциональных точек вместо SLOC в качестве меры функциональности, но с точкой функции тесно связана с SLOC (и не может быть измерена автоматически) это не является повсеместно распространенным мнение.

пример

По словам Винсента Maraia значения SLOC для различных операционных систем в Microsoft «s Windows NT линейки продуктов заключаются в следующем:

Год Операционная система SLOC (миллион)
1993 Windows NT 3.1 4-5
1994 Windows NT 3.5 7-8
1996 Windows NT 4.0 11-12
2000 Windows 2000 более 29
2001 Windows XP 45
2003 Windows Server 2003 50

David A. Wheeler изучал Red Hat распределение операционной системы Linux , и сообщил , что Red Hat Linux версии 7.1 (выпущен апреля 2001) содержала более 30 миллионов физических SLOC. Он также экстраполировать , что, если бы она была разработана с помощью традиционных патентованных средств, это потребовало бы около 8000 человеко-лет усилий в области развития и будет иметь стоимость более $ 1 млрд рублей (в год 2000 долларов США).

Позже Аналогичное исследование было сделано в Debian GNU / Linux версии 2.2 (также известной как «картошка»); эта операционная система была выпущена в августе 2000. Это исследование показало , что Debian GNU / Linux 2.2 включен над 55000000 SLOC, и если они будут разработано в обычном патентованном способе потребовался бы 14,005 человеко-лет и стоило 1,9 $ млрд долларов на разработку. Более поздние пробеги инструментов , используемых отчет , что следующий выпуск Debian было 104 млн SLOC, и по состоянию на 2005 год, то новый релиз будет включать по 213 млн SLOC.

Можно найти цифры основных операционных систем (различные версии Windows, которые были представлены в таблице выше).

Год Операционная система SLOC (миллион)
2000 Debian 2.2 55-59
2002 Debian 3.0 104
2005 Debian 3.1 215
2007 Debian 4.0 283
2009 Debian 5.0 324
2012 Debian 7.0 419
2009 OpenSolaris 9,7
FreeBSD 8,8
2005 Mac OS X 10.4 86
1991 Linux ядра 0,01 0.010239
2001 Linux ядра 2.4.2 2,4
2003 Linux ядра 2.6.0 5,2
2009 Linux ядра 2.6.29 11,0
2009 Linux ядра 2.6.32 12,6
2010 Linux ядра 2.6.35 13,5
2012 Linux ядра 3,6 15,9
2015-06-30 Ядро Linux предварительно 4,2 20,2

Полезность

преимущества

  1. Область применения для автоматизации подсчета: Так как строка кода является физическое лицо; ручное усилие подсчета могут быть легко устранены за счет автоматизации процесса подсчета. Малые коммунальные услуги могут быть разработаны для подсчета LOC в программе. Тем не менее, логическая утилита код подсчета разработанная для конкретного языка не может быть использована для других языков из-за синтаксические и структурные различия между языками. Физические счетчики LOC, однако, были произведены, которые рассчитывают на десятках языков.
  2. Интуитивный Метрика: строка кода служит интуитивным метрики для измерения размера программного обеспечения , потому что это можно увидеть и эффект от него может быть визуализированы. Функциональные точки называются более объективной метрики , которые нельзя представить как физическое лицо, оно существует только в логическом пространстве. Таким образом, LOC пригождается , чтобы выразить размер программного обеспечения среди программистов с низким уровнем опыта.
  3. Вездесущие Мера: меры LOC были примерно с первых дней программного обеспечения. Таким образом, можно утверждать, что более LOC данные доступны, чем любая другая мера размера.

Недостатки

  1. Отсутствие ответственности: Линии коды меры страдает от некоторых фундаментальных проблем. Некоторые считают, что это не полезно для измерения производительности проекта, используя только результаты от этапа кодирования, который обычно составляет только 30% до 35% от общих усилий.
  2. Отсутствие сплоченности с функциональностью: Хотя эксперименты неоднократно подтверждали , что в то время как усилия тесно связаны с LOC, функциональность менее хорошо коррелирует с LOC. То есть, опытные разработчики могут развивать такую же функциональность с гораздо меньшим количеством кода, так что одна программа с меньшим количеством LOC может проявлять больше функциональных возможностей, чем другой аналогичной программы. В частности, LOC является низкая производительность мера индивидов, потому что разработчик , который развивается лишь несколько строк все еще может быть более продуктивным , чем разработчик создает больше строк кода — даже больше: некоторые хорошие рефакторинга , как «метод Extract» , чтобы избавиться от избыточный код и держать его в чистоте будет в основном уменьшить строки коды.
  3. Неблагоприятное воздействие на Оценка: В связи с тем, представленным под пунктом № 1, оценки, основанные на строках коды могут негативно ошибется, по всей возможности.
  4. Разработчика Опыт: Реализация определенной логики различается в зависимости от уровня опыта разработчика. Следовательно, число строк кода отличается от человека к человеку. Опытный разработчик может реализовать определенную функциональность в меньшем количестве строк коды, чем другой разработчик относительно меньшего опыта делает, хотя они используют один и тот же язык.
  5. Разница в Языки: Рассмотрим два приложения, которые обеспечивают такую ​​же функциональность (экраны, отчеты, базы данных). Одно из приложений написано на C ++ и других приложениях, написанных на языке, как COBOL. Количество функциональных точек будет точно такой же, но аспекты применения будут отличаться. Строки кода, необходимые для разработки приложения, конечно, не то же самое. Как следствие, количество усилий, необходимых для разработки приложения будут разные (часов в точке функции). В отличие от строк кода, количество функциональных точек будет оставаться постоянным.
  6. Наступление GUI Tools: С появлением графического интерфейса на основе языков программирования и инструментов , таких как Visual Basic , программисты могут писать относительно немного кода и достичь высокого уровня функциональности. Например, вместо того , чтобы писать программу , чтобы создать окно и нарисовать кнопку, пользователь с помощью инструмента GUI можно использовать перетащить и падение и другие операции с мышью для размещения компонентов на рабочей области. Код , который генерируется автоматически с помощью инструмента GUI, обычно не принимаются во внимание при использовании методов LOC измерения. Это приводит к изменению между языками; та же задача , что может быть сделано в одной строке кода (или без кода вообще) на одном языке , может потребоваться несколько строк кода в другой.
  7. Проблемы с несколькими языками: В современном сценарии программного обеспечения, программное обеспечение часто развиваются в более чем одном языке. Очень часто, ряд языков используются в зависимости от сложности и требований. Отслеживание и отчетность о производительности и дефектной ставок представляет собой серьезную проблему в данном случае, поскольку дефекты не могут быть отнесены к конкретному языку последующей интеграции системы. Функция точка выделяется, чтобы быть лучшим показателем размера в этом случае.
  8. Отсутствие счетных стандартов: Там нет стандартного определения того, что строка коды. подсчитывать ли комментарии? Включены объявления данных? Что произойдет, если заявление распространяется на несколько строк? — Это те вопросы, которые часто возникают. Хотя такие организации, как SEI и IEEE опубликовали некоторые рекомендации в попытке унифицировать подсчет, то трудно поставить их на практику, особенно в условиях новых и новых языков, внедряемых с каждым годом.
  9. Психология: Программист, чья производительность измеряется в строках кода будет иметь стимул писать излишне подробный код. Чем больше управление сосредотачивается на строках кода, тем больше стимул программист должен расширить свой код с ненужной сложности. Это нежелательно, поскольку повышенная сложность может привести к увеличению стоимости обслуживания и увеличению усилий, необходимых для исправления ошибок.

В PBS документальный Триумф полудурков , Microsoft исполнительный Стив Баллмер раскритиковал использование подсчета строк кода:

В IBM есть религия в программное обеспечение , которое говорит , что вы должны рассчитывать K-Locs и K-LOC в тысячу строк кода. Насколько большой это проект? О, это своего рода проект 10К-LOC. Это 20K-LOCer. И это 50K-LOCs. И IBM хотела рода сделать это религия о том , как мы заплатили. Сколько денег мы убежали OS / 2 , сколько они сделали. Сколько K-LOCs вы делали? И мы все время пытались убедить их — эй, если у нас есть — разработчик получил хорошую идею , и он может получить что — то сделано в 4K-оргкомитетах вместо 20K-оргкомитетов, мы должны сделать меньше денег? Потому что он сделал что — то меньше и быстрее, меньше K-LOC. K-LOCs, K-LOCs, это методология. Тьфу! Во всяком случае, это всегда делает мою спину просто завивать при мысли о всех вещах.

Количество строк кода (Lines of code)


Определение

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

Физические и логические строки

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

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

Пример расчета

Рассмотрим следующий код:

В данном случае получается, что в коде содержится 2 физические строки кода, 2 логические строки кода (оператор цикла for и оператор вызова функции printf) и 1 строка комментария.

Если поменять форматирование кода:

то получим уже 5 физических строк кода, но при этом останутся те же 2 логических строки кода и 1 строка комментария.

Количество строк и характеристики программы

Количество строк кода, очевидно, ассоциируется со сложностью системы — чем больше кода, тем она сложнее. Для примера, ядро операционной системы Windows NT 3.1 оценивается в 4-5 миллионов строк кода, а уже Windows XP — 45 миллионов. Количество строк кода в ядре Linux версии 2.6 равняется 5.6 миллионов, а версии 3.6 — уже 15.9 миллионов.

А вот с качеством и надежностью все не так однозначно. В реальном мире все программы содержат ошибки, и скорее всего, чем больше программа, тем больше ошибок. Это довольно очевидное утверждения, если ввести коэффициент «количество ошибок/количество кода» — даже если он будет постоянным, абсолютное число ошибок будет возрастать вместе с ростом программы. А интуиция подсказывает, что при увеличении кода число будет увеличиваться из-за возрастающей сложностью системы (Э. Таненбаум). И не только интуиция (см. график «типичная плотность ошибок»). На подобных соображениях основываются такие принципы разработки, как KISS, DRY, и SOLID. Также можно привести красноречивую цитату классика Э. Дейкстры — «простота — основа надежности», а также отрывок его работы «Плоды непонимания»:

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

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

Строки: таблица символов ASCII и её использование

Введение

В этой статье мы детально рассмотрим таблицу символов ASCII и как ее можно использовать. Также мы рассмотрим несколько новых функций, принцип работы которых основан на специфике строения таблицы ASCII, и в конце создадим новую библиотеку, в которую включим эти функции. Они достаточно популярны в других языках программирования, но их нет среди встроенных функций языка MQL4. Кроме того, мы очень детально разберем основы работы со строками, так что, я думаю, вы обязательно узнаете что-нибудь новое про этот полезный тип данных.

Что такое ASCII ?

ASCII — Американский стандарт кодирования для передачи информации (American Standard Code for Information Interchange). Этот стандарт основан на английском алфавите. Коды ASCII представляют текст в компьютерах, коммуникационном оборудовании и других устройствах, которые работают с текстом. ASCII был создан в 1963 году, но впервые опубликован как стандарт в 1967 году. Последние изменения были внесены в 1986 году. Более детальную информацию про ASCII вы можете почитать здесь: https://en.wikipedia.org/wiki/ASCII. Далее мы рассмотрим как можно полностью вывести ASCII средствами MQL4, но для начала давайте рассмотрим основы работы со строками.

Основы построения библиотеки

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

Разберем значение каждой строки отдельно.

Определяем три переменные типа string:

  • s1 — начальная строка, которую мы хотим обработать;
  • s2 — строка, в которую будет выведен результат;
  • symbol — строка, которая используется для временного хранения каждого символа.

Обратите внимание на то, что она инициализируется одним символом. Если этого не сделать, то в результате получим строку, в которой нет первого символа. Дело в том, что стандартная функция языка MQL4 StringSetChar() изменяет уже созданные символы, поэтому требуется хотя бы один символ для нормальной работы.

Определяем переменную целого типа для хранения длины строки. Для этого сразу же вызываем стандартную функцию для определения длины строки StringLen(), которая имеет единственный параметр — строку, длину которой требуется узнать.

Выводим строку до обработки.

Определяем цикл, в котором будет производиться посимвольная обработка. Обратите внимание, что счетчик инициализируется нулем, так как символы в строке индексируются с нуля, так же как и в массивах. В условии выполнения цикла используется оператор сравнения «меньше», так как последний символ имеет позицию lenght — 1.

В этой строке используется две стандартные функции: StringSetChar() и StringGetChar(). Первая позволяет заменить один из символов строки, а вторая получить код символа в указанной позиции. Функция StringSetChar() имеет три параметра:

  • строку, в которой требуется произвести замену символа;
  • позиция символа, который следует заменить (помните, что символы индексируются с нуля, как в массивах);
  • код символа, которым следует произвести замену.

Функция возвращает результат в виде уже измененной строки. Еще одна важная функция — StringGetChar. Она имеет два параметра:

  • строку, в которой содержится символ, код которого нужно узнать;
  • позиция символа, код которого следует узнать.

Функция возвращает код символа. Так как функция StringGetChar возвращает код символа, то я разместил ее вызов на месте параметра функции StringSetChar. Таким образом с помощью этой строки мы запоминаем текущий символ для дальнейшей обработки. В ходе выполнения всего цикла этой переменной будет по очереди присвоен каждый символ строки s1.

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

Как видно, теперь вместо цикла for используется while, что позволяет избавиться от счетчика x. Для этих целей используется переменная lenght. В дальнейшем мы будем использовать один из этих двух шаблонов для написания функций в зависимости от того, имеет ли значение, в какой последовательности производить обработку. В нашем случае получим строку, в которой символы переставлены наоборот, то есть здесь последовательность обработки имеет большое значение.

Выводим все символы ASCII

Скрипт использует встроенные функции MQL4, а также строковые константы новой строки и табуляции для наглядного представления таблицы. Теперь скомпилируйте и запустите его. Вы должны увидеть таблицу символов ASCII:

Рассмотрите ее повнимательнее. Вы заметите абсолютно все символы, которые только могут понадобиться, от цифр и букв до специальных символов, некоторые из которых вы наверняка увидите впервые. Сначала идет код, а потом после знака «=» сам символ. Я выделил некоторые важные наборы символов для большей наглядности:

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

StringUpperCase и StringLowerCase

Это две очень популярные функции для перевода строки в верхний или нижний регистр. Их реализация основана на том факте, что все коды символов букв верхнего регистра на 32 больше букв нижнего регистра. Это можно увидеть, если смотреть по таблице, что мы получили. На практике, если попробовать узнать коды символов ‘А’,’Я’,’а’, ‘я’, например, с помощью такого кода

то получим результаты: А = 192, Я = 223, а = 224 и я = 255 соответственно. Поэтому следует учесть и эту особенность. Рассмотрим исходный код функций:

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

StringCompare

В MQL4 сравнение строк реализовано на уровне операторов с помощью «==». Интересно, что сравнение является регистрозависимым, то есть строки «STRING» и «string» — разные:

Если нужно сравнить две строки без учета регистра, воспользуйтесь функцией StringCompare. Она возвращает значения типа bool аналогично оператору сравнения. Сама реализация крайне проста. Сравниваются строки, которые до этого приведены к нижнему регистру:

StringIsDigit

Эта функция проверяет содержимое строки. Если строка состоит только из цифр, то возвращает true, иначе false. Реализация довольно проста и основана на том, что символы цифр расположены в ряд и имеют коды от 48 до 58.

StringIsAlpha

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

Создание библиотеки

Теперь давайте соберем все эти функции в одну библиотеку. Для этого в редакторе MetaEditor 4 кликаем File->New->Library->Далее. В поле name пишем stringProcess и нажимаем на кнопку Готово. Потом вставляем код всех функций, приведенных выше, затем сохраняем. Осталось создать файл с прототипами функций, для этого File->New->Include(*. MQH)->Далее. В поле name пишем stringProcess, -> Готово. Теперь нужно вставить прототипы всех новых функций, а также указать директиву для импорта:

Использование библиотеки stringProcess

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

Заключение

Итак, вы узнали что такое таблица символов ASCII и каким образом можно использовать особенности ее строения для реализации новых функций. Вы написали новые функции, которые являются довольно популярными в других языках программирования, но которых нет в MQL4. На основе их вы создали небольшую библиотеку для обработки строк. Я думаю, что эта библиотека будет использоваться не при самой торговле, но при выводе результатов. Например, если вы занимаетесь разработкой собственной системы отчетов для своего эксперта, то некоторые функции будут довольно полезными. Кроме того, наверняка найдется много областей применения, о которых я не подозреваю. Удачи вам и профитов.

Что такое строка кода?

Я понимаю, что нет однозначно «правильного» ответа на этот вопрос, но когда люди говорят о строках кода, что они имеют в виду? Например, в C++ вы считаете пустые строки? Комментарии? линии с открытой или закрытой скобкой?

Я знаю, что некоторые люди используют LoC в качестве меры производительности, и мне интересно, существует ли здесь стандартное соглашение. Кроме того, я думаю, что есть способ заставить различные компиляторы считать строки кода — есть ли там стандартное соглашение?

20 ответов

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

Это может заставить вас спросить: «Почему тогда я буду использовать LOC в качестве меры производительности?» и ответ таков: потому что на самом деле не имеет значения, как вы подсчитываете строку кода, при условии, что вы подсчитываете их последовательно, вы можете получить представление об общем размере проекта по отношению к другим.

Взгляните на статью из Википедии, особенно раздел » Измерение SLOC «:

Существует два основных типа мер SLOC: физический SLOC и логический SLOC. Конкретные определения этих двух показателей различаются, но наиболее распространенное определение физического SLOC- это количество строк в тексте исходного кода программы, включая строки комментариев. Пустые строки также включены, если только строки кода в разделе не содержат более 25% пустых строк. В этом случае пустые строки, превышающие 25%, не учитываются в строках кода.

Логические меры SLOC пытаются измерить количество «операторов», но их конкретные определения привязаны к конкретным компьютерным языкам (одна простая логическая мера SLOC для C-подобных языков программирования — это число точек с запятой в конце оператора). Гораздо проще создавать инструменты для измерения физического SLOC, а физические определения SLOC легче объяснить. Однако физические меры SLOC чувствительны к логически нерелевантным соглашениям о форматировании и стилях, в то время как логические SLOC менее чувствительны к соглашениям о форматировании и стилях. К сожалению, меры SLOC часто указываются без их определения, и логический SLOC часто может существенно отличаться от физического SLOC.

Рассмотрим этот фрагмент кода на C как пример неоднозначности, возникшей при определении SLOC:

В этом примере мы имеем:

  • 1 Физические строки кода LOC
  • 2 логические строки кода lLOC (для выписки и выписки printf)
  • 1 строка комментария
  • количество комментариев
  • количество пустых строк, потому что они важны для читабельности, но не более, чем одна
  • строки с фигурными скобками тоже учитываются, но применяются те же правила, что и для пустых строк — т.е. 5 вложенных фигурных скобок без кода между ними считаются одной строкой.

Я также смиренно предположил бы, что любой показатель производительности, который на самом деле зависит от значения LoC, является двухъярусным:)

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

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

Если вы используете LOC в качестве меры производительности, вы внезапно обнаружите, что ваши программисты гораздо более многословно пишут «игра в систему». Это глупая мера, и только глупые люди используют ее для чего-то большего, чем просто хвастовство.

Все, что «wc -l» возвращает, является моим номером.

«Строки кода» должны включать все, что вы должны поддерживать. Это включает в себя комментарии, но исключает пробелы.

Если вы используете это как показатель производительности, убедитесь, что вы делаете разумные сравнения. Строка C++ отличается от строки Ruby.

1 строка = 4 секунды чтения. Если требуется больше, чем это, чтобы понять, что я говорю по этой строке, строка слишком длинная.

Вы должны думать о » потраченных строках кода», а не о «произведенных строках кода».

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

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

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

LOC — заведомо неоднозначная метрика. Для подробного сравнения он действителен только при сравнении кода, написанного на том же языке, с тем же стилем, той же командой.

Тем не менее, он обеспечивает определенное понятие сложности, когда рассматривается в представлении о порядке величины. Программа на 10000 строк намного сложнее, чем программа на 100 строк.

Преимущество LOC заключается в том, что wc -l возвращает его, и в отличие от многих других программных метрик, в его понимании или расчете нет никакой изощренности.

Там нет правильного ответа.

Для неофициальных оценок я использую wc -l.

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

Если бы я делал это в Scheme или Lisp, я бы посчитал выражения.

Как уже говорили другие, самое главное, чтобы ваш счет был последовательным. Также важно, для чего вы это используете. Если вы просто хотите, чтобы потенциальный новый сотрудник знал, насколько велик ваш проект, используйте wc -l. Если вы хотите заняться планированием и оценкой, возможно, вы захотите стать более формальными. Вы не должны ни при каких обстоятельствах использовать LOC для расчета компенсации программисту.

Понятие LOC — это попытка количественно определить объем кода. Как указывалось в других ответах, не имеет значения, что вы конкретно называете строкой кода, если вы последовательны. Интуитивно кажется, что программа из 10 строк меньше, чем программа из 100 строк, которая меньше, чем программа из 1000 строк и так далее. Вы можете ожидать, что для создания, удаления и поддержки 100-строчной программы требуется меньше времени, чем для 1000-строчной. Неформально, по крайней мере, вы можете использовать LOC, чтобы получить приблизительное представление о количестве работы, необходимой для создания, отладки и поддержки программы определенного размера.

Конечно, есть места, где это не держится. Например, сложный алгоритм, отображаемый в 1000 строк, может быть намного сложнее разработать, чем, скажем, простая программа базы данных, которая потребляет 2500 строк.

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

Я думаю об этом как о едином обрабатываемом утверждении. Например

В мире.NET, похоже, существует глобальное соглашение о том, что строка кода (LoC) является точкой последовательности отладки. Точка последовательности — это единица отладки, это часть кода, выделенная темно-красным цветом при установке точки останова. С точкой последовательности мы можем говорить о логическом LoC, и эту метрику можно сравнить по различным языкам.NET. Метрика логического кода LoC поддерживается большинством инструментов.NET, включая метрику кода VisualStudio, NDepend или NCover.

Метод 8 LoC (точки последовательности в начальных и конечных скобках не учитываются):

В отличие от физического LoC (имеется в виду просто подсчет количества строк в исходном файле), логический LoC имеет огромное преимущество — он не зависит от стиля кодирования. Мы все согласны с тем, что стиль кодирования может варьировать физический подсчет LoC на порядок от одного разработчика к другому. Я написал более подробный пост в блоге на эту тему: Как вы подсчитываете количество строк кода (LOC)?

Я использую wc -l для быстрой оценки сложности рабочего пространства. Тем не менее, как показатель производительности LOC является худшим. Я вообще считаю, что это очень продуктивный день, если мой, если LOC счетчик идет вниз.

Я знаю, что некоторые люди используют LoC в качестве меры производительности

Не могли бы вы сказать мне, кто они, чтобы я не работал с ними (или, что еще хуже, с ними)?

Если я могу реализовать в 1400 строк, используя Haskell, то, что я мог бы реализовать в 2800 строк, используя C, я более продуктивен в C или Haskell? Что займет больше времени? Какие из них будут иметь больше ошибок (подсказка: это линейно по количеству LOC)?

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

При этом, как вы считаете, LOCs? Простой, использовать wc -l , Почему это правильный инструмент? Что ж, вы, вероятно, не заботитесь о каком-то конкретном числе, но об общих общих тенденциях (повышение или понижение и насколько), об отдельных тенденциях (повышение или понижение, смена направления, как быстро, . ) и о почти все, кроме числа 82 763.

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

Посчитай сколько раз ‘\n’ происходит. Другие интересные персонажи могут быть ‘;’ , ‘<' а также '/' ,

Илон Маск рекомендует:  Прозрачность в CSS3. Свойство opacity
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL