Методическая разработка – логично структурированный и подробно описанный ход проведения учебного занятия, мероприятия. Описание последовательности действий должно также включать поставленные педагогом цели, средства их достижения, ожидаемые результаты и сопровождаться соответствующими методическими советами.
Скачать:
Предварительный просмотр:
Методическая разработка – логично структурированный и подробно описанный ход проведения учебного занятия, мероприятия. Описание последовательности действий должно также включать поставленные педагогом цели, средства их достижения, ожидаемые результаты и сопровождаться соответствующими методическими советами.
Методическая разработка – издание, содержащее конкретные материалы в помощь по проведению какого-либо мероприятия, сочетающее описание последовательности действий, отражающих ход его проведения, с методическими советами по его организации.
Методическая разработка – комплексная форма, которая может включать также сценарии, планы выступлений, описание творческих заданий, схемы, рисунки и т.д.
Как оформить реферат по ГОСТУ 2020 года за 5 минут (Пример правильного оформления)
Методическая разработка – это пособие, раскрывающее формы, средства, методы обучения, элементы современных педагогических технологий или сами технологии обучения и воспитания применительно к конкретной теме урока, теме учебной программы, преподаванию курса в целом. Методическая разработка может быть как индивидуальной, так и коллективной работой. Она направлена на профессионально-педагогическое совершенствование преподавателя или мастера производственного обучения или качества подготовки по учебным специальностям.
Методическая разработка может представлять собой:
- разработку конкретного занятия;
- разработку серии занятий;
- разработку темы программы;
- разработку частной (авторской) методики преподавания дисциплины;
- разработку общей методики преподавания дисциплин;
- разработку новых форм, методов или средств обучения и воспитания;
- методические разработки, связанные с изменением материально-технических условий преподавания дисциплины;
- методические разработки, связанные с новыми учебными специальностями, интегрированными специальностями;
Схема методической разработки может включать:
- название разработки;
- сведения об авторе;
- цель;
- перечень используемого оборудования и материалов;
- описание хода проведения мероприятия;
- методические советы по его организации и подведению итогов;
- список использованной литературы;
- приложения (схемы, таблицы, рисунки, тестовые задания, карточки)
К методической разработке предъявляются довольно серьезные требования. Поэтому, прежде чем приступить к ее написанию необходимо:
- тщательно подойти к выбору темы разработки. Тема должна быть актуальной, известной педагогу, по данной теме у педагога должен быть накоплен определенный опыт; определить цель методической разработки;
- внимательно изучить литературу, методические пособия, положительный педагогический опыт по выбранной теме; составить план и определить структуру методической разработки; определить направления предстоящей работы.
Приступая к работе по составлению методической разработки, необходимо четко определить ее цель.
ГОСТ 2022г — Как правильно оформить Курсовую работу | Пример оформления образца
Например, цель может быть следующей: определение форм и методов изучения содержания темы; раскрытие опыта проведения занятий по изучению той или иной темы учебной программы; описание видов деятельности педагога и учащихся; описание методики использования современных технических и информационных средств обучения; осуществление связи теории с практикой на занятиях; использования современных педагогических технологий или их элементов на занятиях и т.д.
Требования, предъявляемые к методической разработке:
Структура методической разработки:
- Титульный лист
- Рецензия (внешняя, внутренняя)
- В аннотации (рецензии) кратко указывается, какой проблеме посвящается методическая разработка, какие вопросы раскрывает, кому может быть полезна (1 страница). Во введении (пояснительной записке) раскрывается актуальность данной работы, т.е. автор отвечает на вопрос, почему он выбрал эту тему и каково ее место в содержании образования (1-2 страницы). В заключении (1-2 страницы) подводятся итоги по тем проблемным вопросам, которые ставились педагогом, приступая к составлению методической разработки.
Общие требования к оформлению методической разработки
- Общий объем методической разработки (исключая приложения) должен составлять не менее 24 листов компьютерного текста (шрифт 14 Times New Roman ). Если методическая разработка представляет собой разработку одного урока, то не менее 10 листов.
- Объем основного содержания — не менее половины всей рукописи.
- Объем приложений не лимитируется, но они должны соответствовать тексту (ссылки на них в тексте обязательны).
- Ссылки на использованную литературу в тексте следует давать в квадратных скобках.
- Список использованных источников должен содержать 10-15 названий. Если разработка носит только практический характер, не требующий теоретических ссылок, то список использованных источников можно опустить.
- Количество и объем разделов не лимитируется.
Методические рекомендации – вид методической продукции, раскрывающий порядок, логику и акценты изучения какой-либо темы, проведения занятия, мероприятия. В методических рекомендациях акцент делается не столько на последовательность осуществляемых действий (как в методической разработке), сколько на раскрытие одной или нескольких частных методик, выработанных на основе положительного опыта. Задача методических рекомендаций – пропагандировать наиболее эффективные, рациональные варианты, образцы действий применительно к определенному виду деятельности (в том числе — мероприятию). В методических рекомендациях обязательно содержится указание по организации и проведению одного или нескольких конкретных дел, иллюстрирующих описываемую методику на практике.
Методические рекомендации – это один из видов методической продукции (наряду с методической разработкой, методическим пособием, дидактическим материалом). Методические рекомендации представляют собой особым образом структурированную информацию, определяющую порядок, логику и акценты изучения какой-либо темы, проведения занятия, мероприятия.
Методические рекомендации содержат в себе раскрытие одной или нескольких частных методик, выработанных на основе положительного опыта. Их задача – рекомендовать наиболее эффективные, рациональные варианты, образцы действий применительно к определенному виду деятельности (в том числе к мероприятию). В методических рекомендациях обязательно содержится указание по организации и проведению одного или нескольких конкретных дел, иллюстрирующих методику на практике. Методические рекомендации должны иметь точный адрес (указание на то, кому они адресованы: педагогам, родителям, методистам, педагогам-организаторам, классным руководителям и т.д.). Соответственно этому регламентируется терминология, стиль, объем методических рекомендаций.
Структура методических рекомендаций
- Титульный лист
- Рецензия (внешняя, внутренняя)
- Пояснения к отдельным структурным элементам методических рекомендаций На титульном листе должны быть обозначены:
- название учреждения (в порядке нисходящей подчиненности);
- название;
- фамилия, имя, отчество автора;
- название города;
- год разработки.
На втором листе вверху приводится аннотация, включающая лаконичные сведения о:
- сути рассматриваемых вопросов;
- предназначении данных методических рекомендаций (какую помощь и кому призвана оказать настоящая работа);
- источнике практического опыта, положенного в основу рекомендаций (указать, на базе какого опыта разработаны данные метод.рекомендации);
- возможных сферах приложения предлагаемого вида методической продукции (в каких областях гуманитарного знания могут быть использованы настоящие рекомендации).
Внизу второго листа помещаются сведения об авторе (авторах): Ф.И.О., должность, место работы, квалификационная категория или научная степень, контактный телефон.
Пояснительная записка должна содержать следующую информацию:
- обоснование актуальности разработки данных методических рекомендаций (здесь целесообразно дать краткий анализ положения дел по изучаемому вопросу: уточнить, в каких образовательных областях в настоящее время используются мероприятия (действия, методики и др.), сходные с предлагаемыми, в чем их достоинства и недостатки; охарактеризовать значимость предлагаемой работы с точки зрения реализации соответствующей федеральной или региональной программы; разъяснить, какую помощь и кому могут оказать настоящие методические рекомендации);
- определение цели предлагаемых методических рекомендаций (например: оказать методическую помощь педагогам-практикам, организаторам воспитательной работы с детьми по вопросам … ; составить алгоритм подготовки и проведения … мероприятия и т.п.);
- краткое описание ожидаемого результата от использования данных методических рекомендаций в системе образования (например: овладение опытом организации предлагаемой методикой может стать основой для проведения подобных мероприятий по разным предметам; может способствовать повышению мотивации студентов и т.п.);
- обоснование особенностей и новизны предлагаемой работы в сравнении с другими подобными разработками, существующими в данной образовательной области.
- описать (на основе состоявшегося опыта деятельности), что именно рекомендуется делать по исследуемому вопросу (поэтапно) и как (с помощью каких форм и методов;
- дать советы по решению:
- организационных вопросов (например, разработать план работы оргкомитета; определить этапы проведения мероприятия и сроки информирования его потенциальных участников, распределить поручения, обеспечить рекламную кампанию и т.д.); материально-техническому обеспечению (Интернет-ресурсы);
- финансовому обеспечению (источники и фиксированные суммы финансирования данного мероприятия),
- кадровому обеспечению (требования к экспертам);
- вычленить наиболее трудные моменты в организации и проведении описываемого вида деятельности (исходя из имеющегося опыта);
Список рекомендуемой литературы по теме рекомендаций составляется в алфавитном порядке, в соответствии с современными правилами оформления литературных источников.
Приложения включают материалы, необходимые для организации рекомендуемого вида деятельности с использованием данных методических рекомендаций, но не вошедшие в блок «Содержание». В числе приложений могут быть:
- планы проведения конкретных дел, мероприятий;
- тестовые задания;
- методики создания практических заданий, адресованных обучающимся;
- примерные вопросы к играм, конкурсам, викторинам;
- методики определения результатов по конкретным видам деятельности;
- схемы, диаграммы, фотографии, карты, ксерокопии архивных материалов;
- примерная тематика открытых мероприятий, экскурсий и т.д.
Общие требования к оформлению методических рекомендаций
- Общий объем методических рекомендаций (исключая приложения) должен составлять не менее 24 листов компьютерного текста (шрифт 14 Times New Roman ).
- Объем основного содержания — не менее половины всей рукописи.
- Объем приложений не лимитируется, но они должны соответствовать тексту (ссылки на них в тексте обязательны).
- Ссылки на использованную литературу в тексте следует давать в квадратных скобках.
- Список использованных источников должен содержать 10-15 названий. Если разработка носит только практический характер, не требующий теоретических ссылок, то список использованных источников можно опустить.
- Количество и объем разделов не лимитируется.
Методическое пособие – комплексный вид методической продукции, включающий в себя особым образом систематизированный материал, раскрывающий суть, отличительные особенности и методики какого-либо образовательного курса. Как правило, методическое пособие, помимо теоретического, содержит обширный дидактический материал в виде иллюстраций, таблиц, диаграмм, рисунков, а также образцы документов, разработанных в соответствии с заявленной тематикой.
Методическое пособие – комплексный вид методической продукции, обобщающий значительный опыт, накопленный в системе дополнительного образования детей и содержащий рекомендации по его использованию и развитию.
Авторами методических пособий являются, как правило, опытные педагоги и методисты, способные систематизировать практический материал собственной работы и работы коллег по профессии, учесть и использовать в обосновании предлагаемых методик теоретические разработки современной педагогики дополнительного образования детей.
Задачей методического пособия является оказание практической помощи педагогам и методистам в приобретении и освоении передовых знаний как теоретического, так и практического характера.
Типовая структура методического пособия включает:
- введение, где формулируются цель и задачи данного пособия, указывается, на какую конкретную группу студентов, какие конкретные результаты может дать педагогам и методистам использование данного пособия;
- теоретическую часть, где излагается, как правило, в краткой форме (при необходимости с отсылкой к соответствующим работам) научно-педагогическое обоснование содержания пособия, характеризуется собственная методологическая позиция автора применительно к системе дополнительного образования детей как сфере образования, обладающей своими специфическими чертами;
- практическую часть, где систематизируется и классифицируется фактический материал, содержатся практические рекомендации, приводятся характерные примеры тех или иных форм и методик работы;
- дидактическую часть, в которой сосредоточены дидактические материалы (схемы, таблицы, рисунки и т. п.), иллюстрирующие практический материал.
Кроме того, в состав методического пособия могут включаться различные необходимые нормативные документы, использование которых позволит педагогу или методисту организовать свою работу в соответствии с имеющимися требованиями.
Обязательной частью методического пособия является список литературы, который желательно оформить с разделением на тематические рубрики (в соответствии с конкретными задачами, решаемыми в данном пособии) и, по возможности, с краткими аннотациями наиболее полезных педагогам и методистам рекомендуемых работ.
Структура методического пособия:
- Титульный лист
- Рецензия (внешняя, внутренняя)
- Структура пособия (разработка)
- Титульный лист
- Рецензия
- ( если методическое пособие для студентов)
- Технологическая карта
(если методическое пособие для преподавателей)
- Граф-логические структуры
- Работа
- Тестовые задания
- Эталоны ответов
- Глоссарий
- Литература
Источник: nsportal.ru
Как правильно оформлять программу
2. Используйте информативные названия. Ваши коллеги и разработчики должны быть в состоянии выяснить, какой у вас тип переменной и что она хранит по имени. Короче говоря, ваш код должен быть легко читаемым и осмысленным.
# Not recommended c = [“UK”, “USA”, “UAE”] for x in c: print(x) # Recommended cities_list = [“UK”, “USA”, “UAE”] for city in cities_list: print(city)
3. Всегда используйте один и тот же словарь. Соблюдайте соглашение об именах. Соблюдение принятого соглашения об именах важно для устранения путаницы, когда другие разработчики работают над вашим кодом.
И это относится к именованию переменных, файлов, функций и даже структур каталогов.
# Not recommended client_first_name = ‘John’ customer_last_name = ‘Doe; # Recommended client_first_name = ‘John’ client_last_name = ‘Doe’ # Another example: # bad code def fetch_clients(response, variable): # do something pass def fetch_posts(res, var): # do something pass # Recommended def fetch_clients(response, variable): # do something pass def fetch_posts(response, variable): # do something pass
4. Не используйте магические числа. Магические числа — это числа со специальной жестко заданной семантикой, которые появляются в коде, но не имеют никакого значения или объяснения. Обычно эти числа появляются как литералы более чем в одном месте кода.
import random # Not recommended def roll_dice(): return random.randint(0, 4) # what is 4 supposed to represent? # Recommended DICE_SIDES = 4 def roll_dice(): return random.randint(0, DICE_SIDES)
2.2. Функции
5. Длинные имена != описательные имена. Вы должны подробно описывать, но только релевантную информацию.
Например, хорошие имена функций описывают то, что они делают хорошо, не включая подробности о реализации или узкоспециальном использовании.
DICE_SIDES = 4 # Not recommended def roll_dice_using_randint(): return random.randint(0, DICE_SIDES) # Recommended def roll_dice(): return random.randint(0, DICE_SIDES)
6. Следуйте соглашению о присвоении имен функций . Как видно из приведенных выше переменных, придерживайтесь соглашения при именовании функций. Использование различных соглашений об именах могло бы сбить с толку других разработчиков и коллег.
# Not recommended def fetch_user(id): # do something Pass def get_post(id): # do something pass # Recommended def fetch_user(id): # do something Pass def fetch_post(id): # do something pass
7. Не используйте флаги, в том числе логические. Логические флаги — это переменные, которые содержат логическое значение — true или false . Эти флаги передаются функции и используются функцией для определения ее поведения.
text = «Python is a simple and elegant programming language.» # Not recommended def transform_text(text, uppercase): if uppercase: return text.upper() else: return text.lower() uppercase_text = transform_text(text, True) lowercase_text = transform_text(text, False) # Recommended def transform_to_uppercase(text): return text.upper() def transform_to_lowercase(text): return text.lower() uppercase_text = transform_to_uppercase(text) lowercase_text = transform_to_lowercase(text)
2.3. Классы
8. Не добавляйте лишний контекст.
Это может произойти из-за добавления ненужных переменных к именам переменных при работе с классами.
# Not recommended class Person: def __init__(self, person_username, person_email, person_phone, person_address): self.person_username = person_username self.person_email = person_email self.person_phone = person_phone self.person_address = person_address # Recommended class Person: def __init__(self, username, email, phone, address): self.username = username self.email = email self.phone = phone self.address = address
3. Использование пустого пространства
3.1. Отступ
Организуйте для своего кода последовательный отступ, стандартом является использование 4 пробелов для каждого отступа. Вы можете сделать это по умолчанию в текстовом редакторе. При использовании отступа следует учитывать следующее: в первой строке не должно быть аргументов, а дальнейший отступ должен использоваться для четкого выделения в качестве продолжения строки:
# Correct: # Aligned with opening delimiter. foo = long_function_name(var_one, var_two, var_three, var_four) # Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one) # Hanging indents should add a level. foo = long_function_name( var_one, var_two, var_three, var_four)
# Wrong: # Arguments on first line forbidden when not using vertical alignment. foo = long_function_name(var_one, var_two, var_three, var_four) # Further indentation required as indentation is not distinguishable. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
3.2. Максимальная длина линии
Постарайтесь ограничить свои строки примерно 79 символами, что является рекомендацией, приведенной в руководстве по стилю PEP 8 . Во многих хороших текстовых редакторах есть настройка для отображения тонкой линии, указывающей, где находится ограничение в 79 символов.
3.3. Пустые строки
Добавление пустых строк в ваш код сделает его лучше, чище и понятнее. Вот простое руководство по добавлению пустых строк в ваш код:
- Окружите определения функций и классов верхнего уровня двумя пустыми строками.
- Определения методов внутри класса отделены пустой строкой.
- Дополнительные пустые строки могут использоваться (экономно) для разделения групп связанных функций. Пустые строки могут быть опущены между набором связанных однострочников (например, набор фиктивных реализаций).
- Осторожно используйте пустые строки в функциях для обозначения логических разделов.
4. Комментарии и документация
Как бы мы ни старались писать чистый код, в вашей программе все равно будут части, требующие дополнительных пояснений. Комментарии позволяют нам быстро рассказать другим разработчикам (и самим себе в будущем), почему мы написали это именно так. Однако будьте осторожны, так как слишком много комментариев может сделать ваш код более сложным для восприятия, чем он был бы без них.
4.1. Встроенные комментарии
Встроенные комментарии — это текст, следующий за символами решетки по всему коду. Они используются для объяснения частей вашего кода и действительно помогают будущим участникам понять вашу работу.
Одним из способов использования комментариев является документирование основных шагов сложного кода, чтобы помочь читателям следить за ними. Тогда, возможно, вам не нужно будет досконально вникать в код, чтобы понять, что он делает. Однако другие утверждают, что такое использование комментариев служит скорее для оправдания плохого кода, и если код требует комментариев, это признак того, что необходим рефакторинг.
Комментарии полезны для пояснений, когда код не может объяснить, почему он был написан таким образом или почему были выбраны определенные значения . Например, почему тот или иной метод был реализован определенным образом. Иногда может применяться нестандартный или кажущийся произвольным подход из-за какой-то неясной внешней переменной, вызывающей проблемы. Эти вещи трудно объяснить с помощью кода.
Вот несколько советов, как писать хорошие комментарии:
1. Не комментируйте плохой код, перепишите его
Комментирование плохого кода поможет вам только в краткосрочной перспективе. Рано или поздно одному из ваших коллег придется поработать с вашим кодом, и он в конечном итоге перепишет его, потратив несколько часов на то, чтобы понять, что он делает. Поэтому лучше переписать плохой код с самого начала, чем просто комментировать его.
2. Не добавляйте комментарии, когда в этом нет необходимости.
Если ваш код достаточно читаем, вам не нужны комментарии. Добавление бесполезных комментариев только сделает ваш код менее читаемым. Вот плохой пример:
# This checks if the user with the given ID doesn’t exist. if not User.objects.filter(id=user_id).exists(): return Response(< ‘detail’: ‘The user with this ID does not exist.’, >)
Как правило, если вам нужно добавить комментарии, они должны объяснять, почему вы что-то сделали, а не то, что происходит.
3. Не оставляйте закомментированный устаревший код
Худшее, что вы можете сделать, — это оставлять закомментированный код в своих программах. Весь отладочный код или отладочные сообщения должны быть удалены перед отправкой в систему контроля версий, иначе ваши коллеги побоятся их удалить, а ваш закомментированный код останется там навсегда.
4.2. Строки документации
Docstrings, или с троки документации, — это ценные фрагменты документации, которые объясняют функциональность любой функции или модуля в вашем коде. В идеале каждая из ваших функций всегда должна иметь docstrings , которые заключаются в тройные кавычки.
Первая строка docstrings представляет собой краткое объяснение назначения функции. Следующий элемент строки документации — это объяснение аргументов функции. Здесь вы перечисляете аргументы, указываете их назначение и типы. Наконец, обычно приводится некоторое описание вывода функции.
Каждая часть строки документации является необязательной; однако строки документа являются частью хорошей практики кодирования. Ниже приведены два примера строки документации для функции. В первом будет использоваться однострочная строка документации, а во втором — многострочные строки документации:
def population_density(population, land_area): «»»Calculate the population density of an area.»»» return population / land_area
def population_density(population, land_area): «»»Calculate the population density of an area. Args: population: int. The population of the area land_area: int or float. This function is unit-agnostic, if you pass in values in terms of square km or square miles the function will return a density in those units. Returns: population_density: population/land_area.
The population density of a particular area. «»» return population / land_area
4.3. Документация
Документация по проекту необходима для того, чтобы другие понимали, почему и как ваш код актуален для них, независимо от того, являются ли они потенциальными пользователями вашего проекта или разработчиками, которые могут внести свой вклад в ваш код.
Отличным первым шагом в проектной документации является файл README . Очень часто это будет первым взаимодействием большинства пользователей с вашим проектом. Будь то приложение или пакет, к вашему проекту обязательно должен быть приложен файл README. Как минимум он должен содержать объяснения того, что он делает, и перечисления зависимостей, а также предоставлять достаточно подробные инструкции о том, как его использовать. Это поможет другим понять цель вашего проекта и быстро получить что-то работающее.
Формальное изложение всех ваших идей и мыслей на бумаге может быть немного сложным, но со временем у вас будет лучше получаться, а также вы существенно поможете другим осознать ценность вашего проекта. Написание этой документации также может помочь вам улучшить дизайн вашего кода, поскольку вам придется более тщательно продумывать свои проектные решения. Кроме того, пользователям будет легче понять, как использовать ваш код.
Материалы по теме
Источники
Источник: proglib.io
Правила оформления качественного кода. Как правильно оформлять код.
Во время написания кода начинающие программисты зачастую даже не задумываются над тем, как именно следует его оформлять. «Да и зачем? — думают они. — Программа же и так прекрасно работает!». Для очень маленьких учебных задач и проектов, возможно, это допустимо, однако не просто же так крупные компании, как например, Google, создают огромные гиды (code style guide) с правилами написания кода внутри компании. Если вы действительно хотите развиваться как программист, превращаясь из начинающего кодера в крутого профессионального разработчика, то правил написания кода избежать попросту не удастся. Да и зачем избегать, если умение корректно оформить код является ценным навыком, поскольку в разы облегчает работу тех программистов, которым придётся с вами работать! В нашей статье речь будет идти в основном про языки C и C++, однако большую часть из них легко перенести на любой другой язык программирования.
Отступы и пробелы в коде
Отступы являются, пожалуй, самым главным критерием хорошей читаемости кода. А когда код читается без всяких затруднений, разбираться в нём становится гораздо легче.
Отделяйте пробелами фигурные скобки.
Переносите объявления нескольких переменных на новые строки.
Отделяйте пустой строкой объявления переменных и действия с ними (кроме присваивания):
// так делать не стоит: int x = 5, y; long v = -1; x++; double pi = 3.1415926; if (value == x) < func(); >// лучше написать так: int x = 5; int y; long v = -1; double pi = 3.1415926; x++; if (value == x)
Разделяйте пробелами операторы и операнды:
// так делать не стоит: int expr = (x+y)*z/sqrt(x*x+y*y+z*z)-func(); // лучше написать так: int expr = (x + y) * z / sqrt(x * x + y * y + z * z) — func();
Если строка стала слишком длинной, разделите её на несколько, сделав перевод на новую строку после оператора:
int value1 = veryVeryLongFunctionNameOne() + veryVeryLongFunctionTwo() + veryVeryLongFunctionNameThree() + 456; int value2 = veryVeryLongFunction(longParameterOne, longParameterTwo, longParameterThree, longLongLongParameterFour, longParameterFive);
Разделяйте пустой строкой реализации функций:
// так делать не стоит: void func1() < // . реализация функции 1 >void func2() < // . реализация функции 2 >// лучше написать так: void func1() < // . реализация функции 1 >void func2() < // . реализация функции 2 >
Пропускайте пробел перед открывающей фигурной скобкой, а также перед открывающей круглой скобкой после операторов if , for , while , switch и тд:
// так делать не стоит: for(int i = 0; i < 10; i++)< if(data[i] % 2)< count++; >> // лучше написать так: for (int i = 0; i < 10; i++) < if (data[i] % 2) < count++; >>
Скобки и пустые строки
Не добавляйте пустую строку после открывающей ( < ) и перед закрывающей ( >) фигурными скобками:
// так делать не стоит: if (a > b) < /* лишняя пустая строка */ c = a — b; while (c >(a + b) / 2) < c /= 2; /* лишняя пустая строка */ >> // лучше написать так: if (a > b) < c = a — b; while (c >(a + b) / 2) < c /= 2; >>
Добавляйте после закрывающей фигурной скобки ( > ) пустую строку, но только если за ней что-то есть и это не ещё одна закрывающая скобка:
// так делать не стоит: for (int i = 0; i < 10; i++) < if (a == i) < func(); >/* лишняя пустая строка */ > /* не хватает пустой строки */ func2(); // лучше написать так: for (int i = 0; i < 10; i++) < if (a == i) < func(); >> func2();
Разделяйте логически связанные группы выражений, добавляя пустую строку между ними:
// так делать не стоит: . vector points = getPoints(f); cout << «Readed points: » << endl; printPoints(points); vectorgrahamPoints = grahamHull(points); cout << «GrahamHull points: » << endl; printPoints(grahamPoints); vectorjarvisPoints = jarvisHull(points); cout << «JarvisHull points: » << endl; printPoints(jarvisPoints); . // лучше написать так: . vectorpoints = getPoints(f); // получение точек // вывод считанных данных cout << «Readed points: » << endl; printPoints(points); // получение данных с помощью одного метода и вывод результатов vectorgrahamPoints = grahamHull(points); cout << «GrahamHull points: » << endl; printPoints(grahamPoints); // получение данных с помощью второго метода и вывод результатов vectorjarvisPoints = jarvisHull(points); cout
Переменные, функции, константы и их названия
«Как вы яхту назовёте, так она и поплывёт!» — пелось в песенке капитана Врунгеля. Вот и в программировании примерно так: как вы переменную назовёте, так она и должна использоваться! Опытные программисты даже могут не один час провести в раздумьях всего лишь из-за поиска подходящего названия!
Давайте переменным имена, по которым сразу будет понятно, для чего они используются: если нужно посчитать сумму положительных элементов массива, логичнее будет назвать переменную sumOfPositiveElement , нежели просто s или sum . Или если требуется найти среднее из элементов, назовите переменную average или avg . Старайтесь избегать однобуквенных названий вроде x или c (к этому совету не относятся переменные циклов вроде i , j и тд.).
В зависимости от используемого языка слова в именах переменных разделяются либо с помощью символа нижнего подчёркивания, либо через верблюжийРегистр (каждое новое слово записывается с заглавной буквы). Если же таковые правила отсутствуют, выберите наиболее удобный вам и всегда придерживайтесь его в дальнейшем. Классы обычно называются в ПаскальномРегистре , а константы или макросы в ВЕРХНЕМ_РЕГИСТРЕ .
Если переменная используется внутри определённого if или while блока, то делайте её локальной, объявляя в том же блоке кода, а не глобальной:
// так делать не стоит: int status; int value = getValue(word, dictionary); if (value > 0) < . status = checkValue(value, correctValues); . return status; >// лучше написать так: int value = getValue(word, dictionary); if (value > 0)
Избегайте «магических» констант в коде (простые, ничего не значащие цифры). Обозначьте их как const и ссылайтесь на константы, а не на значения:
// так делать не стоит: for (int i = 0; i < 3; i++) < for (int j = 0; j < 7; j++) < if (field[i, j] == 0) showError(451); >> // лучше написать так: const int FIELD_HEIGHT = 3; // высота поля const int FIELD_WIDTH = 7; // ширина поля const int ZERO_FIELD_CODE = 451; // код ошибки в случае нулевой ячейки поля . for (int i = 0; i < FIELD_HEIGHT; i++) < for (int j = 0; j < FIELD_WIDTH; j++) < if (field[i, j] == 0) showError(ZERO_FIELD_CODE); >>
Циклы и условные операторы
Циклы позволяют выполнять один код несколько раз, однако существуют различные виды циклов. Для каждой ситуации один цикл может подойти лучше, а другой хуже.
Используйте цикл for , когда количество повторений заранее известно, а цикл while , если число итераций заранее посчитать невозможно:
// повторять ‘size’ раз for (int i = 0; i < size; i++) < . >// повторять, пока есть что считывать Point p; while (std::cin >> p.x >> p.y)
При использовании операторов цикла ( for / while / do-while ) или условных операторов( if / else ) всегда ставьте фигурные скобки и соответствующие отступы, даже если тело всего оператора состоит всего из одной строки:
// так делать не стоит: if (isWin(gameField)) return; else for (int i = 0; i < freeCells.size(); i++) freeCells[i].calcValue(); // лучше написать так: if (isWin(gameField)) < return; >else < for (int i = 0; i < freeCells.size(); i++) < freeCells[i].calcValue(); >>
Старайтесь свести практику использования операторов break и continue к минимуму, а лучше вовсе откажитесь от неё. Используйте их только в случае крайней необходимости.
Используя оператор if / else , избегайте проверки лишних условий внутри операторов:
// так делать не стоит: if (max >= 100) < func1(); >if (max >= 50 max < 100) < func2(); >if (max >= 25 max < 50) < func3(); >// лучше написать так: if (max >= 100) < func1(); >else if (max >= 50) < func2(); >else if (max >= 25)
Если вам требуется вернуть логическое выражение, записанное внутри if / else , возвращайте это выражение:
// так делать не стоит: if (gameField.getFreeCellsCount() == 0) < return true; >else < return false; >// лучше написать так: return gameField.getFreeCellsCount() == 0;
Повторение частей кода
Если вы используете один и тот же код более одного раза, найдите способ удалить лишнее или перенесите его в отдельную функцию и вызывайте её вместо старых блоков. Если повторяющийся код похож лишь частично, то постарайтесь вынести различающиеся части в параметры вспомогательной функции:
// так делать не стоит: Move move = makeMove(human); gameField[move].player = human; player = ai; steps++; Move move = makeMove(ai); gameField[move].player = ai; player = human; steps++; // лучше написать так: void gameMove(Player currentPlayer) < Move move = makeMove(currentPlayer); gameField[move].player = currentPlayer; player = currentPlayer == human ? ai : human; steps++; >gameMove(human); gameMove(ai);
Если какой-то код повторяется во всех частях if / else блока, то вынесите этот код за пределы условного оператора:
// так делать не стоит: if (a > b) < value = a + b; a = b; func(); >else < value = a + b; b = a; func(); >// лучше написать так: value = a + b; if (a > b) < a = b; >else < b = a; >func();
Эффективность
Вызывая большую функцию и используя результат несколько раз, сохраните результат в переменной вместо того, чтобы постоянно вызывать данную функцию:
// так делать не стоит: if (indexOfElement(list, element) > -1) < removeElementAtIndex(list, indexOfElement(list, element)); /* второй раз вычисляется значение функции */ >// лучше написать так: int index = indexOfElement(list, element); if (index > -1) removeElementAtIndex(list, index);
Программист, сооснователь programforyou.ru, в постоянном поиске новых задач и алгоритмов
Языки программирования: Python, C, C++, Pascal, C#, Javascript
Выпускник МГУ им. М.В. Ломоносова
Programforyou — это сообщество, в котором Вы можете подтянуть свои знания по программированию, узнать, как эффективно решать те или иные задачи, а также воспользоваться нашими онлайн сервисами.
Источник: programforyou.ru