Как найти ошибку в коде c

Затем идет метод пристального взгляда, когда вы пытаетесь определить, что пошло не так, внимательно читая то, что вы написали, и перепроверяя. Для этих моментов полезно писать простой и легко читаемый код.

Следующие макросы помогут эффективно выводить в консоль переменные с их названиями и значениями, контейнеры вроде std::vector и std::set , а также пары значений вида std::pair .

О школе программирования 21

Примерно серию таких тестов вам надо будет пройти прежде чем вы попадете в бассейн. Советую их вам внимательно посмотреть.

Пример правильного оформленя кода C по нормам школы 21

Вот пример правильного оформления кода с комментариями (если будете загонять его на проверку - удалите комментарии) Так же напоминаю, что если вас не просят написать main (как в этой функции), то делать это не надо. Ниже будет список ошибок (которые удобно находить по command+F): буду редактировать и дополнять пост всеми ошибками, которые мне встретятся, с описанием их исправления. Напоминаю, что для проверки стоит использовать команду norminette -R CheckForbiddenSourceHeader в директории с программой на с) Для проверки файлов типа *.h используется только norminette, без флагов. P.S. Спасибо за ваши лайки! Я чувствую, что писал этот пост не зря.) P.S.S. А для любителей есть вот такая штука https://forum.intra.42.fr/topics/20837/messages/last 12 - она позволяет раскрашивать вывод norminette. . Ошибки в коде Error: global scope bad aligned Найдите в своей функции строчку с объявлением функции вида int main. Удалите пробел после int и вставьте после него два

Архив

• 10 правил, чтобы научиться плавать в бассейне
• Пример правильного оформленя кода C по нормам школ.
• Стандарты написания кода в 21-school: The Norm
• Гайд по тому, как минимизировать шанс получения ти.
• Вот что такое проверка norminette в школе 21
• Проверка кода C online
• Что такое ТИЖ (TIJ) и с чем его едят
• Видео школы программирования 21
• Начальные тесты, для того чтобы попасть в бассейн
• Экзамены в школе программирования 21
• Тестирование своего кода
• РЕГИСТРИРУЙТЕСЬ НА ПРОЕКТЫ!
• Вот так выглядит календарь бассейна на июль 2019
• FAQ бокала шоклы программирования 21
• Как проверять свой код с помощью тестов 42 Stupidity
• Что такое Slack
• Таблица видео и документов бассейна с внутреннего .
• А вот ну очень крутой чел с уровнем 21 (самый высо.
• Day10 Makefile
• Получение ТИЖа за отказ от защиты группового проек.
• Делаем проверку norminette удобнее
• Названия проектов школы программирования 21 на осн.
• Помощь на интре школы программирования 21
• Хорошая справка по командам редактора VIM
• Проверка заданий moulinette
• 42 header for VIM
• Настройки vim и zsh
• 42homebrew
• Книга всех времен и народов по Си
• Примеры проверки moulinette
• Big brother watch you.
• Лирика бассейна школы программирования 21
• Перевод задания BSQ
• Скрипт генерации карт для BSQ
• Проверка скорости работы BSQ
• Как быстро разобраться с указателями в Си
• В школе программирования 21 сперциально создают ст.
• Выдержки из официальных документов школы программи.
• Немного про экзамены в школе программирования 21
• TIJелая жизнь участников бассейна!
• Правила финального экзамена школы программирования 21
• Советы для решения задач на экзамене.
• Как не наступить на грабли на экзаменах!
• Holy Graph 42 Карта проектов школы программировани.

Показать больше Показать меньше

Популярное

Пример правильного оформленя кода C по нормам школы 21

Вот пример правильного оформления кода с комментариями (если будете загонять его на проверку - удалите комментарии) Так же напоминаю, что если вас не просят написать main (как в этой функции), то делать это не надо. Ниже будет список ошибок (которые удобно находить по command+F): буду редактировать и дополнять пост всеми ошибками, которые мне встретятся, с описанием их исправления. Напоминаю, что для проверки стоит использовать команду norminette -R CheckForbiddenSourceHeader в директории с программой на с) Для проверки файлов типа *.h используется только norminette, без флагов. P.S. Спасибо за ваши лайки! Я чувствую, что писал этот пост не зря.) P.S.S. А для любителей есть вот такая штука https://forum.intra.42.fr/topics/20837/messages/last 12 - она позволяет раскрашивать вывод norminette. . Ошибки в коде Error: global scope bad aligned Найдите в своей функции строчку с объявлением функции вида int main. Удалите пробел после int и вставьте после него два

Начальные тесты, для того чтобы попасть в бассейн

Примерно серию таких тестов вам надо будет пройти прежде чем вы попадете в бассейн. Советую их вам внимательно посмотреть.

Стандарты написания кода в 21-school: The Norm

Среди мануалов и файлов школы затерялся замечательный файл The Nom - Coding Standard - Academy+Plus, в котором описываются стандарты написания кода на с, без соблюдения которых наши программы никогда не смогут пройти проверку больше чем на 0 баллов. Для проверки кода надо открыть в терминале в папку с файлами с исходным кодом и запустить в терминале norminette -R CheckForbiddenSourceHeader ( © @ghildega ). Сам файл можно найти здесь: https://cdn.intra.42.fr/pdf/pdf/960/norme.en.pdf411 Что это за зверь такой - "стандарты написания кода"? https://ru.wikipedia.org/wiki/Стандарт_оформления_кода107 Он полностью на английском, поэтому хочу поделиться с вами своим конспектом-переводом. Я буду рад, если вы поможете мне уточнить перевод в комментариях! Для этого достаточно владеть английским на уровне выше INTERMEDIATE и не пользоваться так же активно гугл-перевордчиком, как я) И, как говорится, “Ставьте лайки, подписывайтесь”, ставьте uovotes (Стрелочка вверх), комменти

ДЕНЬ 1. Он же Day 00 🙂

В первый день вы получите два аккаунта. Один это логин и пароль в Slack, другой это логин и пароль в интру школы 42. Ага школы 42, я надеюсь вы уже в курсе почему школы 42, вам это должны были разъяснить на личной встрече. А если у вас еще этой встречи не было и вы читаете мой блог заблаговременно перед поступлением в школу, то вкратце могу сказать что школа программирования 21 от сбербанка это франшиза французской школы программирования 42 . И так еще раз по порядку: 1. Slack - тут вы будете общаться с пирами, то есть с друзьями товарищами по бассейну, а так же с администрацией школы. Это просто групповой чат . В слеке есть гурппы bocal и adm. Так вот в бокал писать только по техническим проблемам . Например комп завис, перезагрузился, мышь не работает и тд и тп. По административным и бытовым проблемам это в адм , вода закончилась на кухне, холодно в кластере, жарко в кластере, открыть окно, закрыт окно, привести гостя и тд и тп. Не путайте эти два канала, иначе вылетите из б

Вот что такое проверка norminette в школе 21

А счастье было так близко. Сейчас можно пользоваться Norminette из дома, а не только из школы программирования 21. Как настроить это в Linux Mint или Ubuntu смотрите в этом видео.

Ответы по результатам бассейна

13 августа стали приходить письма с результатами бассейна. Всего их три типа: 1) Ты принят на основное обучение! 2) Нам надо подумать. 3) Извини но нет 🙁

Как проверять свой код с помощью тестов 42 Stupidity

Переходим в домашний каталог командой cd ~ Клонируем репозиторий командой git clone https://github.com/mirror12k/42us-stupidity.git 42Stupidity Переходим в созданный каталог cd 42Stupidity Клонируем свой репозиторий с залитыми заданиями в каталог внутри каталога 42Stupidity. Например: git clone vogsphere@vogsphere.21-school.ru:intra/2019/activities/piscine_c_day_05/nick day05 Далее даете команду ./spawn.pl day05 config_d05.pl В данном случае day05 это каталог с заданиями day05 и в нем есть подкаталоги ex00, ex01 и т.д. После этого генерируются файлы для создания тестов. Затем даете команду ./tools/build.sh Она уже создает исполняемые файлы с тестами ваших функций. После этого прогоняете тесты на норминет командой ./tools/verify.sh Ну и в конце концов сами тесты. Команда ./tools/check_all.sh

Как выглядит examshell школы программирования 21 (42)

Все эти скрины взяты из видео из предыдущего поста. Там снимали часть на экзамене. Очень рекомендую посмотреть внимательно это видео, чтобы для вас examshell не был чем-то не понятным.

Тестирование своего кода

Как тестировать свой код, чтобы не править его перед отправкой Если тебе надоело в каждую свою функцию постоянно добавлять реализацию ft_putchar и main , по несколько раз править и компилировать до тех пор, пока не заработает, а потом вычищать это перед git push , то можешь сделать так же, как и я. В рабочем каталоге я создал файл test.c со следующим содержанием: # include int ft_putchar ( char c ) < /* Здесь моя реализация ft_putchar (почти такая же, как и в видео к Day02 */ >/* В следующий строке XXXXX надо заменить на имя файла с твоей функцией, которую и надо тестировать Например #include "ex04/ft_print_combo.c" */ # include "XXXXX" int main ( void ) < YYYYY ( ) ; /* Подставь вместо YYYYY имя функции тестируемой, например ft_print_comb(); */ return ( 0 ) ; >Компилирую я это командой: gcc -Wall -Wextra -Werror -o test test.c ,если есть ошибки, то редактирую vim ex04/ft_print_comb.c , и так до тех пор,

Найти ошибку в коде С++

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

#include "stdafx.h" #include "conio.h" #include #include #include "stdio.h" int _tmain(int argc, _TCHAR* argv[]) < setlocale(LC_ALL, "Rus"); int n, m, i, j, flag, dop, g; printf("Введите размер матрицы\n"); scanf_s("%d %d", &n, &m); int **A; A = (int**)malloc(sizeof(int*)*n); for (i = 0; i> g = m; for (i = 1; i A[i][j + 1]) < dop = A[i][j]; A[i][j] = A[i][j + 1]; A[i][j + 1] = dop; flag = 0; >> > while (flag == 1); > for (i = 2; i > > while (flag == 1); > return 0; > 

Отслеживать

44.8k 3 3 золотых знака 38 38 серебряных знаков 89 89 бронзовых знаков

задан 10 дек 2016 в 15:04

525 1 1 золотой знак 5 5 серебряных знаков 17 17 бронзовых знаков

О поиске ошибок в коде

End-to-End тестирование в деталях и примерах

Автоматизация тестирования: перспективно ли?

Как стать тестировщиком — путь к успеху

Какие виды тестирования существуют

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

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

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

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

Понимание кода

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

Рекомендации по структурированию и комментированию кода:

Структурирование кода:

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

Комментирование кода:

• предоставляйте комментарии к большим блокам кода;
• документируйте функции и классы;
• комментируйте временные решения или известные проблемы.

Соблюдение этих принципов делает код более поддерживаемым и снижает вероятность ошибок.

�� Компания Foxminded приглашает вас научиться тестировать код на курсе QA Automation

�� С нами вы не только освоите ключевые инструменты, такие как Selenium Webdriver, JUnit5, TestNG, но и станете экспертом в тестировании ПО, обеспечивая высокое качество кода.

��‍�� Получите индивидуальный менторинг, погрузитесь в практику, и через 6-8 месяцев вы будете готовы к новым вызовам в мире QA Automation.

Использование отладчиков

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

• GDB (GNU Debugger): универсальный отладчик для C, C++, Java, Python и других языков.
• Visual Studio Debugger: встроенный отладчик в среду разработки Visual Studio. Поддерживает множество функций, включая пошаговое выполнение, проверку переменных и просмотр стека вызовов.
• Xcode Debugger: встроенный отладчик в среду разработки Xcode. Предоставляет функции пошагового выполнения, проверки переменных и просмотра стека вызовов.

Примеры использования отладчиков в различных средах программирования

Пример 1: GDB (С, C++)

$ gcc -g -o my_program my_program.c # Compile with debugging information $ gdb ./my_program # Launch GDB for analysis (gdb) break main # Set a breakpoint in the main function (gdb) run # Run the program (gdb) step # Step through the code (gdb) print variable_name # Print the value of a variable (gdb) backtrace # Output the call stack

Пример 2: Visual Studio Debugger (C#)

• Откройте проект в Visual Studio.
• Установите точку останова, кликнув левой кнопкой мыши слева от строки кода.
• Нажмите «Start Debugging» или используйте горячую клавишу F5.
• При остановке выполнения на точке останова, анализируйте значения переменных и используйте другие функции отладчика.

Пример 3: Xcode Debugger (Swift)

• Откройте проект в Xcode.
• Установите точку останова, щелкнув слева от строки кода.
• Запустите приложение в режиме отладки.
• При остановке выполнения на точке останова, используйте инструменты Xcode Debugger для анализа состояния переменных, трассировки стека и шагания по коду.

Логирование и мониторинг

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

Логи могут помочь вам:

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

Пример 1: Логирование событий (Python)

import logging # Configuring the logger logging.basicConfig(filename='app.log', level=logging.DEBUG) # Example usage def process_data(data): try: result = data['value'] / data['divisor'] logging.info(f"Successfully processed data: ") return result except Exception as e: logging.error(f"Error processing data: ") raise

Пример 2: Логирование веб-приложения (Node.js)

const express = require('express'); const winston = require('winston'); const app = express(); // Configuring the logger const logger = winston.createLogger(< transports: [ new winston.transports.File(< filename: 'app.log' >), new winston.transports.Console(), ], format: winston.format.simple(), >); // Example usage app.get('/api/data', (req, res) => < try < // Processing the request logger.info('Data request processed successfully.'); res.status(200).send('Data retrieved successfully.'); >catch (error) < logger.error(`Error processing data request: $`); res.status(500).send('Internal Server Error'); > >); app.listen(3000, () => < logger.info('Server is running on port 3000'); >);

Эти примеры демонстрируют базовую реализацию логирования для обнаружения ошибок и отслеживания ключевых событий в приложении. Важно правильно настроить уровни логирования (debug, info, error) и использовать их сообразно контексту, чтобы логи не становились избыточными, но предоставляли достаточно информации для успешной отладки.

Тестирование кода

Тестирование — это процесс проверки правильной работы кода. Оно может помочь выявить ошибки на ранней стадии разработки.

Существует два основных типа тестирования:

• Автоматическое (юнит-тесты, интеграционные, и тесты приемочного тестирования (E2E) — выполняются автоматически, с использованием скриптов и инструментов.
• Ручное — выполняется человеком вручную, включает в себя проверку функциональности приложения.

Примеры тестовых сценариев для выявления ошибок

Пример 1: Юнит-тестирование (Python)

# Code to be tested def add_numbers(a, b): return a + b # Unit test def test_add_numbers(): assert add_numbers(2, 3) == 5 # Positive scenario assert add_numbers(-1, 1) == 0 # Positive scenario assert add_numbers(0, 0) == 0 # Positive scenario assert add_numbers(2, -3) == -1 # Positive scenario assert add_numbers('Hello', 'World') == 'HelloWorld' # Negative scenario (data types)

Пример 2: Интеграционное тестирование (JavaScript, используя Jest)

// Code to be tested function fetchData() < // Some code for fetching data >// Integration test test('fetchData retrieves data from the API', async () => < const data = await fetchData(); expect(data).toBeDefined(); // Check that data is retrieved expect(data.length).toBeGreaterThan(0); // Check that data is not empty >);

Работа с сообществом

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

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

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

Также не размещайте сообщения, не относящиеся к теме обсуждения.

При формулировании вопросов старайтесь быть четкими и краткими, что ускорит получение полезных ответов.

Рефакторинг и пересмотр кода

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

Похожие материалы

End-to-End тестирование в деталях и примерах

Автоматизация тестирования: перспективно ли?

Как стать тестировщиком — путь к успеху

Какие виды тестирования существуют

Что делать, если программа не компилируется?

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

Как отследить ошибку в логике программы?

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

Как исправить ошибку, если я не могу понять, в чем она заключается?

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

Может ли проблема быть связана с внешними библиотеками?

Да, убедитесь, что вы используете правильные версии библиотек и правильно их подключили.

Какие инструменты могут помочь в поиске ошибок?

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

Стоит ли обращаться за помощью к другим?

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

Как найти ошибки в коде

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

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

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

Тесты

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

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

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

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

Утверждения

Утверждение — это специальная функция, которая вызывает ваш код с определенными параметрами и проверяет, что он возвращает ожидаемый результат. Например:

assert(isPrime(3)); assert.equal(factorial(3), 6);

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

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

assert.js:89 throw new assert.AssertionError( < ^ AssertionError: 3 == 1 at Object.(test.js:4:8) at Module._compile (module.js:413:34) at loader (/usr/local/lib/node_modules/babel-register/lib/node.js:126:5) at Object.require.extensions.(anonymous function) [as .js] (/usr/local/lib/node_modules/babel-register/lib/node.js:136:7) at Module.load (module.js:357:32) at Function.Module._load (module.js:314:12) at Function.Module.runMain (module.js:447:10) at /usr/local/lib/node_modules/babel-cli/lib/_babel-node.js:161:27 at Object. (/usr/local/lib/node_modules/babel-cli/lib/_babel-node.js:162:7) at Module._compile (module.js:413:34)

Вывод можно разделить на две части:

• Первая — описание того, что ожидалось от функции и что было получено. В нашем примере это строка AssertionError: 3 == 1 . Читается она следующим образом: «ожидалось, что функция вернет 3, но она вернула 1». Это уже хорошо, но еще хотелось бы увидеть, с какими параметрами была вызвана функция. И в этом нам поможет вторая часть вывода.
• Вторая часть называется backtrace, она содержит список функций, которые последовательно вызывались в коде. Порядок вывода, чаще всего, обратный: в начале то, что вызывалось последним.
  В первую очередь нужно, начиная с конца, найти первое упоминание функции из файла, который похож на тестовый. Обычно его называние содержит слово test. В примере выше это at Object. (test.js:4:8) . В скобках указана строчка, на которой находится вызов этого утверждения. В данном случае — строчка 4.
  Всё, что теперь остается, это зайти в соответствующий файл и посмотреть то, как вызывалась ваша функция.

Предупреждения компилятора и интерпретатора

Синтаксические ошибки

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

Другие ошибки

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

Также ошибки содержат вывод backtrace, по которому можно найти то место, в котором возникла ошибка и попробовать его проанализировать.

Многие из этих ошибок легко исправить с помощью отладочной печати (см. урок Отладочная печать).

Последнее обновление более двух недель назад

О школе программирования 21

Примерно серию таких тестов вам надо будет пройти прежде чем вы попадете в бассейн. Советую их вам внимательно посмотреть.

Пример правильного оформленя кода C по нормам школы 21

Вот пример правильного оформления кода с комментариями (если будете загонять его на проверку - удалите комментарии) Так же напоминаю, что если вас не просят написать main (как в этой функции), то делать это не надо. Ниже будет список ошибок (которые удобно находить по command+F): буду редактировать и дополнять пост всеми ошибками, которые мне встретятся, с описанием их исправления. Напоминаю, что для проверки стоит использовать команду norminette -R CheckForbiddenSourceHeader в директории с программой на с) Для проверки файлов типа *.h используется только norminette, без флагов. P.S. Спасибо за ваши лайки! Я чувствую, что писал этот пост не зря.) P.S.S. А для любителей есть вот такая штука https://forum.intra.42.fr/topics/20837/messages/last 12 - она позволяет раскрашивать вывод norminette. . Ошибки в коде Error: global scope bad aligned Найдите в своей функции строчку с объявлением функции вида int main. Удалите пробел после int и вставьте после него два

Архив

• 10 правил, чтобы научиться плавать в бассейне
• Пример правильного оформленя кода C по нормам школ.
• Стандарты написания кода в 21-school: The Norm
• Гайд по тому, как минимизировать шанс получения ти.
• Вот что такое проверка norminette в школе 21
• Проверка кода C online
• Что такое ТИЖ (TIJ) и с чем его едят
• Видео школы программирования 21
• Начальные тесты, для того чтобы попасть в бассейн
• Экзамены в школе программирования 21
• Тестирование своего кода
• РЕГИСТРИРУЙТЕСЬ НА ПРОЕКТЫ!
• Вот так выглядит календарь бассейна на июль 2019
• FAQ бокала шоклы программирования 21
• Как проверять свой код с помощью тестов 42 Stupidity
• Что такое Slack
• Таблица видео и документов бассейна с внутреннего .
• А вот ну очень крутой чел с уровнем 21 (самый высо.
• Day10 Makefile
• Получение ТИЖа за отказ от защиты группового проек.
• Делаем проверку norminette удобнее
• Названия проектов школы программирования 21 на осн.
• Помощь на интре школы программирования 21
• Хорошая справка по командам редактора VIM
• Проверка заданий moulinette
• 42 header for VIM
• Настройки vim и zsh
• 42homebrew
• Книга всех времен и народов по Си
• Примеры проверки moulinette
• Big brother watch you.
• Лирика бассейна школы программирования 21
• Перевод задания BSQ
• Скрипт генерации карт для BSQ
• Проверка скорости работы BSQ
• Как быстро разобраться с указателями в Си
• В школе программирования 21 сперциально создают ст.
• Выдержки из официальных документов школы программи.
• Немного про экзамены в школе программирования 21
• TIJелая жизнь участников бассейна!
• Правила финального экзамена школы программирования 21
• Советы для решения задач на экзамене.
• Как не наступить на грабли на экзаменах!
• Holy Graph 42 Карта проектов школы программировани.

Показать больше Показать меньше

Популярное

Пример правильного оформленя кода C по нормам школы 21

Вот пример правильного оформления кода с комментариями (если будете загонять его на проверку - удалите комментарии) Так же напоминаю, что если вас не просят написать main (как в этой функции), то делать это не надо. Ниже будет список ошибок (которые удобно находить по command+F): буду редактировать и дополнять пост всеми ошибками, которые мне встретятся, с описанием их исправления. Напоминаю, что для проверки стоит использовать команду norminette -R CheckForbiddenSourceHeader в директории с программой на с) Для проверки файлов типа *.h используется только norminette, без флагов. P.S. Спасибо за ваши лайки! Я чувствую, что писал этот пост не зря.) P.S.S. А для любителей есть вот такая штука https://forum.intra.42.fr/topics/20837/messages/last 12 - она позволяет раскрашивать вывод norminette. . Ошибки в коде Error: global scope bad aligned Найдите в своей функции строчку с объявлением функции вида int main. Удалите пробел после int и вставьте после него два

Начальные тесты, для того чтобы попасть в бассейн

Примерно серию таких тестов вам надо будет пройти прежде чем вы попадете в бассейн. Советую их вам внимательно посмотреть.

Стандарты написания кода в 21-school: The Norm

Среди мануалов и файлов школы затерялся замечательный файл The Nom - Coding Standard - Academy+Plus, в котором описываются стандарты написания кода на с, без соблюдения которых наши программы никогда не смогут пройти проверку больше чем на 0 баллов. Для проверки кода надо открыть в терминале в папку с файлами с исходным кодом и запустить в терминале norminette -R CheckForbiddenSourceHeader ( © @ghildega ). Сам файл можно найти здесь: https://cdn.intra.42.fr/pdf/pdf/960/norme.en.pdf411 Что это за зверь такой - "стандарты написания кода"? https://ru.wikipedia.org/wiki/Стандарт_оформления_кода107 Он полностью на английском, поэтому хочу поделиться с вами своим конспектом-переводом. Я буду рад, если вы поможете мне уточнить перевод в комментариях! Для этого достаточно владеть английским на уровне выше INTERMEDIATE и не пользоваться так же активно гугл-перевордчиком, как я) И, как говорится, “Ставьте лайки, подписывайтесь”, ставьте uovotes (Стрелочка вверх), комменти

ДЕНЬ 1. Он же Day 00 :)

В первый день вы получите два аккаунта. Один это логин и пароль в Slack, другой это логин и пароль в интру школы 42. Ага школы 42, я надеюсь вы уже в курсе почему школы 42, вам это должны были разъяснить на личной встрече. А если у вас еще этой встречи не было и вы читаете мой блог заблаговременно перед поступлением в школу, то вкратце могу сказать что школа программирования 21 от сбербанка это франшиза французской школы программирования 42 . И так еще раз по порядку: 1. Slack - тут вы будете общаться с пирами, то есть с друзьями товарищами по бассейну, а так же с администрацией школы. Это просто групповой чат . В слеке есть гурппы bocal и adm. Так вот в бокал писать только по техническим проблемам . Например комп завис, перезагрузился, мышь не работает и тд и тп. По административным и бытовым проблемам это в адм , вода закончилась на кухне, холодно в кластере, жарко в кластере, открыть окно, закрыт окно, привести гостя и тд и тп. Не путайте эти два канала, иначе вылетите из б

Вот что такое проверка norminette в школе 21

А счастье было так близко. Сейчас можно пользоваться Norminette из дома, а не только из школы программирования 21. Как настроить это в Linux Mint или Ubuntu смотрите в этом видео.

Ответы по результатам бассейна

13 августа стали приходить письма с результатами бассейна. Всего их три типа: 1) Ты принят на основное обучение! 2) Нам надо подумать. 3) Извини но нет :(

Как проверять свой код с помощью тестов 42 Stupidity

Переходим в домашний каталог командой cd ~ Клонируем репозиторий командой git clone https://github.com/mirror12k/42us-stupidity.git 42Stupidity Переходим в созданный каталог cd 42Stupidity Клонируем свой репозиторий с залитыми заданиями в каталог внутри каталога 42Stupidity. Например: git clone vogsphere@vogsphere.21-school.ru:intra/2019/activities/piscine_c_day_05/nick day05 Далее даете команду ./spawn.pl day05 config_d05.pl В данном случае day05 это каталог с заданиями day05 и в нем есть подкаталоги ex00, ex01 и т.д. После этого генерируются файлы для создания тестов. Затем даете команду ./tools/build.sh Она уже создает исполняемые файлы с тестами ваших функций. После этого прогоняете тесты на норминет командой ./tools/verify.sh Ну и в конце концов сами тесты. Команда ./tools/check_all.sh

Как выглядит examshell школы программирования 21 (42)

Все эти скрины взяты из видео из предыдущего поста. Там снимали часть на экзамене. Очень рекомендую посмотреть внимательно это видео, чтобы для вас examshell не был чем-то не понятным.

Тестирование своего кода

Как тестировать свой код, чтобы не править его перед отправкой Если тебе надоело в каждую свою функцию постоянно добавлять реализацию ft_putchar и main , по несколько раз править и компилировать до тех пор, пока не заработает, а потом вычищать это перед git push , то можешь сделать так же, как и я. В рабочем каталоге я создал файл test.c со следующим содержанием: # include int ft_putchar ( char c ) < /* Здесь моя реализация ft_putchar (почти такая же, как и в видео к Day02 */ >/* В следующий строке XXXXX надо заменить на имя файла с твоей функцией, которую и надо тестировать Например #include "ex04/ft_print_combo.c" */ # include "XXXXX" int main ( void ) < YYYYY ( ) ; /* Подставь вместо YYYYY имя функции тестируемой, например ft_print_comb(); */ return ( 0 ) ; >Компилирую я это командой: gcc -Wall -Wextra -Werror -o test test.c ,если есть ошибки, то редактирую vim ex04/ft_print_comb.c , и так до тех пор,