Т. е. того самого "неправильно написанного" кода ещё нет.
Нет, уже есть неправильно написанный код - так он содержит потенциальную угрозу. И нужно в таком случаен не аннотации писать, а переделывать его! Разработчик А понял, до начала использования своего кода, что он "плохой" и не стал исправлять, а просто пометил что код плохой. Причём пометил в отдельном месте, а не в коде оставил отметку.
Можете другой пример привести? На этом примере мы что-то никак не можем прийти к согласию )))
Ещё раз уточню: смысл аннотаций не в том, чтобы добавлять их после обнаружения проблемы, а в том, чтобы обнаружить ошибку сразу, как только она будет допущена, потому что для соответствующего метода уже существует аннотация.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
В статье не указано, что разработчик знает о том, что код написан неправильно. Допустим, код был размечен одним разработчиком, знающим об уязвимостях, после чего над проектом начал работать другой, который о них не знает. Он вполне мог написать код, аналогичный тому, что приведён в примере.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди). Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Ещё раз уточню: смысл аннотаций не в том, чтобы добавлять их после обнаружения проблемы, а в том, чтобы обнаружить ошибку сразу, как только она будет допущена, потому что для соответствующего метода уже существует аннотация.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
В статье не указано, что разработчик знает о том, что код написан неправильно. Допустим, код был размечен одним разработчиком, знающим об уязвимостях, после чего над проектом начал работать другой, который о них не знает. Он вполне мог написать код, аналогичный тому, что приведён в примере.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди). Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Показатели успеваемости считали на основании показателей выполнения заданий, учитывали количество попыток и использование подсказок.
Крайние значения были такими:
0 — студент не выполнил ни одного задания (такого не бывает);
+1 — студент выполнил все задания с первой попытки, не используя подсказок (такого тоже не бывает).
Большой вопрос к вашим пониманиям крайних значений. Преподаю давно и были студенты, которые не выполняли ни одного задания. Хотя тут можно вроде и поспорить... Также непонятно как вы считали или узнавали, что студенты не могут выполнить все задания с первой попытки? Сколько было заданий, за какой период, разные ли это темы или всё по одной?..
Вроде про научные подходы пишите, но нет цифр для понимания как пришли к тому, что экстремумы недостижимы.
Статья с хорошими советами, но местами выглядит странно.
Из примеров статьи я понял только то, что разработчик знает, что у него неправильно написан код и пишет аннотации для проверки этого неправильного кода. Не кажется вам, что это звучит странно? Напишем изначально неправильный код (даже для примера) и напишем аннотации для проверки этого неправильного кода. Может есть другие примеры?
Что касается переписывания кода из-за срабатываний PVS-Studio, это вряд ли можно назвать лишней работой.
Это понятно, иначе зачем бы нам нужны были бы анализаторы кода?..
Не совсем понял из статьи зачем мне самому описывать аннотациями узкие/слабые/тонкие места, когда их можно закрыть от потенциальных уязвимостей более правильным написанием кода? Из примера понял, что разработчик по какой-то причине не хочет или не знает как применять параметризированные запросы к БД. Но тогда аннотирование сего кода - это лишняя работа, т.к. всё равно придётся переписывать чтобы убрать предупреждение PVS-Studio?
Два раза встречался с таким подходом на собеседовании - и оба раза мне понравилось. Опыта просмотра кода много, т.к. преподаю и применяю подход: студенты проводят ревью моего кода, а я их. Поэтому более-менее просто могу увидеть что-то что мне не понравится в коде. Но, опять же, у меня один подход к написанию, у кого-то другого - другой. И не всегда он совпадает. Понятно, что есть что-то "фундаментально" как именование, но есть и что-то более размытое. Например, DI (Dependency Injection). Но бывают ситуации, про которые выше уже писали, что на собеседовании ты делаешь ревью кода - а на работе "потом, сейчас некогда...". И это очень печалит.
Спасибо! Этот вариант я понял.
Нет, уже есть неправильно написанный код - так он содержит потенциальную угрозу. И нужно в таком случаен не аннотации писать, а переделывать его!
Разработчик А понял, до начала использования своего кода, что он "плохой" и не стал исправлять, а просто пометил что код плохой. Причём пометил в отдельном месте, а не в коде оставил отметку.
Можете другой пример привести? На этом примере мы что-то никак не можем прийти к согласию )))
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди).
Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди).
Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Большой вопрос к вашим пониманиям крайних значений. Преподаю давно и были студенты, которые не выполняли ни одного задания. Хотя тут можно вроде и поспорить... Также непонятно как вы считали или узнавали, что студенты не могут выполнить все задания с первой попытки? Сколько было заданий, за какой период, разные ли это темы или всё по одной?..
Вроде про научные подходы пишите, но нет цифр для понимания как пришли к тому, что экстремумы недостижимы.
Статья с хорошими советами, но местами выглядит странно.
Очень хороший вариант обучения. В разы лучший - чем "по книжке" или "по видео" наедине с собой.
Из примеров статьи я понял только то, что разработчик знает, что у него неправильно написан код и пишет аннотации для проверки этого неправильного кода. Не кажется вам, что это звучит странно? Напишем изначально неправильный код (даже для примера) и напишем аннотации для проверки этого неправильного кода.
Может есть другие примеры?
Это понятно, иначе зачем бы нам нужны были бы анализаторы кода?..
Спасибо за ответ
Рад, что пригодилось.
Получилось применить вовлечение в повествование при межличностной коммуникации?
Это, к сожалению, ожидаемо.
По теме конкурсов - а хакатоны вам не подходят?
А почему вам не нравится командная работа?
А что преподаёте?
Я советую студентам ходить по собеседованиям и потом с меня спрашивать про то, что не рассказал им или что рассказал не полностью.
P.S. Дополню статью
Ох, первый ваш комментарий и под моей статьёй - как бы вас не посчитали "ботом для накрутки" ))))
Рад что понравились приёмы. Может поделитесь своими или напишите какой больше всего понравился?
Не совсем понял из статьи зачем мне самому описывать аннотациями узкие/слабые/тонкие места, когда их можно закрыть от потенциальных уязвимостей более правильным написанием кода?
Из примера понял, что разработчик по какой-то причине не хочет или не знает как применять параметризированные запросы к БД. Но тогда аннотирование сего кода - это лишняя работа, т.к. всё равно придётся переписывать чтобы убрать предупреждение PVS-Studio?
Два раза встречался с таким подходом на собеседовании - и оба раза мне понравилось. Опыта просмотра кода много, т.к. преподаю и применяю подход: студенты проводят ревью моего кода, а я их. Поэтому более-менее просто могу увидеть что-то что мне не понравится в коде. Но, опять же, у меня один подход к написанию, у кого-то другого - другой. И не всегда он совпадает. Понятно, что есть что-то "фундаментально" как именование, но есть и что-то более размытое. Например, DI (Dependency Injection).
Но бывают ситуации, про которые выше уже писали, что на собеседовании ты делаешь ревью кода - а на работе "потом, сейчас некогда...". И это очень печалит.
Спасибо за пожелание!
Спасибо за комментарий.
P.S. Сразу готовьтесь к тому, что тут могут вас посчитать "типо бота" для поддержки автора (не помню как правильно это называется).