Ну вот это был затык в полезном специфическом софте.
Нет, это был вылезанный из пальца кусок из специфической библиотеке со спорной полезностью, притащенный вдобавок за уши.
сказать по существу
"80% работы программисты - это отладка, но даёт она только 20% результата. Однако без отладки невозможно 80% функциональных возможностей любой программы. Если вы хотите добится успеха, вы должны сначала добиться успеха в отладке."
В работе я пологаюсь на принципе логики Хоора - это привычка доведенная до автоматизма, как слепой ввод в любой современной клавиатуры. Вот и всё, что вы хотели узнать.
Да, в некоторых языках сложнее делать ошибки, в некоторых проще. В rust действительно делать ошибки сложнее, чем в плюсах.
Весь прикол в том, что если в C/C++ ты сделал ошибку, то её так же легко и исправить. Да и далеко не часто делаешь серьёзные ошибки - чаще весь хайп вокруг уязвимостей построен на потенциальных уязвимостях, а не лабораторий ESET, Антивируса Касперского, Dr. Web и прочих институтах, которые целиком занимаются исследования компьютерных вирусов и хакерских атак.
Граждан тут слишком утрирует ситуацию, мол слишком много об уязвимостях говорят (нет, это ты слишком мало читаешь что-то ещё), и теперь я не могу доверять ни одному языку программирования. Отсюда и все дикости с переписыванием стандартной библиотеки и прочий бред.
Серьёзные люди такими дикостями не занимаются. Так же как и давно переросли в себе комплекс перфекциониста, и не ставят себе вопросом жизни и смерти задачу написать идеальную программу с первого раза.
Например, даже в C написать сколь угодно оптимизированный memcpy без совершения UB
Если мне нужно оптимизировать потоки и извлекать меньшие конфликты от ожиданий данных, то ещё с 2010-го года, со стандартами С11, С++11 есть атомарные операции.
Не говоря уже о том, что есть классические семафоры, мониторы и мьютексы, для особо критических случаев, помимо синхронизаций. Там порядочно добавили, на любой вкус.
Я открыто и со словами говорю «покажите, сенсей, какие практики и как в этом коротком, годящемся в учебные примере надо применить, чтобы улучшить код».
Мне неинтересно решать задачки за других, ясно. Лучше киньте тогда что-то более полезное, например затык в полезном специфическом софте. Вот там помогу решить.
"А как ещё помочь человеку, который потерял веру в себя?"
Какую веру в себя? Я всего лишь не верю в собственную абсолютную внимательность (как и в абсолютную внимательность любого другого программиста). Если вы верите, что вы можете 100% времени быть 100% внимательным, то, ну, тут уж я не знаю, что сказать.
Да вы по всему топику о себе много рассказали. Языки вам какие-то не такие. Тестирование для него какое-то не такое. Отлаживать за 10 лет не научился, а скорее всего там и года не было.
Ещё и накидываетесь на других, мол, какие-то не такие. Руку сначала набейте в отладке, тогда и поймёте что вам даёт C, а следом C++.
тут уместно вспомнить, что C++ использует стандартную библиотеку, которую на [стандартном] C++ написать невозможно, точно так же как C использует стандартную библиотеку, которую на [стандартном] С написать невозможно (по крайней мере, в обоих случаях — без UB). И что это значит?
Вы себя послушайте. Вся стандартная библиотека написана базовым синтаксисом языка, и представляет во многом обобщение раннего опыта разработчиков в рамках ещё C89, после дополненных в C99, и расширенных в С++ в 1998 году, и STL, на основе его же синтаксических конструкций, использующих самые продвинутые техники использования языка в 2002 году.
То что в них иногда обнаруживали выходы за границы массивов, переполнения регистров или краш из-за несовпадения последовательности (в данном случае процессор пытается обратиться к несуществующему адрессу) уже говорит о том, что сами современные программисты не соблюдают правила слишком часто, чем программисты поколением до них. Кому тут больше недоверия уже совсем другой вопрос.
Да ё-моё, спрашиваешь у явно опытного в продакшен-разработке человека советов по тому, как бы улучшить код, а тебя в ответ к психологу посылают :(
А как ещё помочь человеку, который потерял веру в себя?
Посоветовать действовать решительней и не воспринимать неоконченную документацию как истину в последней инстанции? Или ещё изложить басню о том, что делать какие-то свои доработки, пусть и только в оформление - это вполне нормальная практика, и в ней нет ничего непристойного?
Не понимаю, почему бы конкретно не сказать на простом и достаточно мелком примере на 50 строк кода.
Я ещё в 2014-м отказался от этой практике на форумах, когда такой приём использовался только чтобы без слов сказать "сделайте всё за меня".
Обычно такие элементарных исходят из того, чтобы можно было только по одним именам функций и их параметров легко определить что они делают, в рамках объекта или модуля в целом.
Если вам этого не достаточно, то разберитесь с форматами данных, которые получаете, и которые выдаёте в конкретных функциях, и уже значительно легче будет понять что с ними делать.
как можно было бы его существенно поменять, но это следующий вопрос.
У вас проявляются все симптомы сильного профессионального выгорания. Тут скорее поможет хороший психолог, чем мои консультации - только вы и люди, с которым вы непосредственно близко общаетесь, знают ваши настоящие мотивации, никто в Сети не сможет вам дать эффективный рецепт для работы над собой и повышения самооценки, не более чем намекнуть, надоумивают обычно либо близкие люди, либо друзья, либо коллеги, либо как раз психологи, которые придметно консультируют.
Как изменения в нейминге могли бы помочь найти висячую ссылку?
Изменения в нейминге сделают код значительно более удобочитабельным, что позволит проще понять его свежим взглядом. И следовательно проще будет найти алгоритмическую ошибку, приводящую к появлению высячих ссылок, утечек памяти и прочих подобных ситуаций.
Такие вещи самособойразумеющиеся и представляют элементарное здравомыслие при написание любой программы.
Было бы очень интересно услышать об этих привычках. Что конкретно стоит взять на вооружение?
Например, логической привязки имён функций и переменных с внутренней логикой модуля, в котором они используются. Очень хорошо это отражено через имена стандартных функций и STL.
Не буду лгать. Очень трудно читать ваш код, он не сложен по структуре, а именно лишен всякой логики в связке с модулем.
Просили прокомментировать. Я полностью согласен с комментарием @shaykemelov от 4 января этого года, 2:53. Поработайте сначала над неймингами функций и переменных, чтобы они были логически связаны с модулем для которого рассчитаны.
Но я всё ещё мечтаю встретить внимательных сверхлюдей, которые не делают ошибок в проектах больше, чем на два часа. Спросил бы у них про их секрет.
На практике такие секреты, скорее обычные профессиональные привычки, которых у вас ещё нет.
Тут всё зависит от того, что подразумевается под ошибком в данном случае.
Умение видеть картину объемно вырабатывается ещё на первых курсах технических вузов. С другой стороны и гуманитариев обижать не стоит, профессионально это называется зуммирование, когда вы смотрите на ситуации не из момента "здесь и сейчас", а в более общем плане, чётко представляя что вы сделали до этого по сравнению с тем, что было до вас.
Если хотите инструментарии, то очень советую обратить внимание на более профессиональные программы трейсировки. На Хабре есть статья "24-ядерный CPU, а я не могу сдвинуть курсор", где наглядно представлена практика работы с такими программами. Я так же с этим работал, когда разбирал выбесшие меня "Системные прерывания" на планшете с Windows 10 - несколько минут в Google, предложили подобную программу от MSI, с помощью её понял, что ОС не могла запустить драйвер встроенной графики и конфликтовала с ним. Дальнейший путь меня привёл к тому, что оказалась проблема в сильно костыльном несовместимом UEFI (он был жестко завязан на Windows 8) - теперь ожидает, когда у меня появится снова программатор, чтобы уже окончательно разобраться с этой проблемой.
Но я всё ещё мечтаю встретить внимательных сверхлюдей, которые не делают ошибок в проектах больше, чем на два часа. Спросил бы у них про их секрет.
Всё очень просто. Доверие.
Когда вы пытаетесь искать везде только изъяны, то неизбежно становитесь заложником своих же предрассудков и постепенно, но неминуемо превращаетесь в параноика.
Программирование подобно течению. Для того чтобы подчинить его своей воли, нужно ему поддаться. И для начала перестать скрести по сусекам и выбрать что-то конкретно определенное.
Ваша самая большая ошибка, в том что вы исчите изъян в инструменте, когда вся ваша речь один большой синтез и не может иметь строго одного определения.
Воззразите: А что с этим делать?
Достаточно ответить только на один вопрос: "А что ожидают от программы, кроме того, чтобы она делала то что от неё требуется и не выводила из себя её пользователя?"
Что и называется, "работает без нареканий".
Здесь и отличие хорошего программиста от плохого. Хороший программист уже по привычке следует негласным правилам хорошего тона, плохой такой привычки ещё не имеет. Хорошо, когда хотя бы стремятся подражать, плохо - когда человек находит любое удобное объяснения своему равнодушию.
Тексты комментариев и статей во всём Интернете всегда одного цвета. Но это не мешает ориентироваться по заголовкам.
Когда же весь текст у тебя как Новогодняя Ёлка, украшенная довольно безвкусно, то это неизбежно утомляет при его чтение, а выделяет мало или зачастую там, где это не имеет смысла.
Такие вещи понимаешь из опыта, может кому-то это более интересно, поэтому я больше за кастомизацию плагинами, а не тупо "поставим пользователей перед фактом, у них всё равно нет другого выбора". Выбор есть всегда, нужно просто уметь его найти.
"К чему тогда все ваши притензии? Может тогда это только вы плохо знаете основы программирования"
Вполне возможно. В конце концов, я уже давно пишу очень мало кода, который бы запускался.
"и просто невнимательны?"
А вот это не «возможно», а абсолютно точно так. Я про себя знаю, что я невнимателен, забывчив, могу писать код не выспавшись, могу встречаться с чужим кодом, где я понял не все детали, и так далее.
Занимательно. Невозможно успеха в работе, если не умеешь расслабляться, с одной стороны. И при этом вы словно ничего не пытались изменить - с другой.
Тут уже скорее выбор инструментов под себя, нежели поиски каких-то "идеальных языков программирования", языки лишь способ изложения, программу создаёт уже компилятор.
Я не спорю, что именно вам полезны инструменты статического анализа, всё таки лучше всего они справляются именно с опечатками.
С другой стороны лучше уже привить себе привычку писать код разборчиво, чтобы его изначально было удобно читать. Тоже и касается и редактора кода - если бы мне пришлось работать только на Visual Studio, то как минимум в первую очередь я сделал плагин, который возвращает классическое выделение и напрочь убрал цветное выделение, кроме классического зелёного для препроцессора и директив компилятора и синего для значений констант. Наблюдать постоянную ЛГБТ-подсветку, которую ещё трудно отключить, во всём исходнике довольно утомительное удовольствие.
Вы читать вообще умеете? Я предлагал адаптировать код, использовать наработки из прошлых проектов, а не публиковать. И никто публиковать это в свободный доступ тут не собирался.
Да, для программистов этот навык очень важен и необходим, но в наше время он не является достаточным - в зависимости от специфики проекта и его прикладной области существует еще очень много вещей, которые должен знать и уметь разработчик, и которые вы не проверите "небольшой программкой" вообще никак.
Только вы одного не учитываете. Я беру кейсы на основе реальной практики, а не каких-то псевдофилософских предположений, как вы.
По одной вашей манере речи можно судить какой вы специалист. Вам бы уже давно только на этом основание указали на дверь. Может вы забыли, но мы говорим не о начинающих, а об уже сформировавшихся специалистах.
Например, вам нужен синьор,
Я и без вас знаю, когда нужен сеньор, а когда прекрасно справится мидл. Ни у меня, ни у моих коллег нет традиции усложнять себе работу, спасибо.
Или вам нужен человек, хорошо разбирающийся в написании интерпретаторов скриптовых языков с JIT-компиляторами
Вряд ли в таком вообще возникнет необходимость. В инженерии, где я работаю, и в более зрелых коммерческих областях предпочитают опираться на более зрелые и документированные стандарты, нежели выдумывать велосипеды на каждый чих.
Да мне абсолютно всё равно, кто он здесь. Даже если он копипастил чужие мануалы по написанию драйверов, то это далеко ещё значит, что он сам написал хотя бы один реально рабочий драйвер.
Хатаб больше сделал для общества, чем ваш @0xd34df00d, который даже псевдоним человеческий не мог сочинить и прикрывается адрессацией.
Нет, это был вылезанный из пальца кусок из специфической библиотеке со спорной полезностью, притащенный вдобавок за уши.
"80% работы программисты - это отладка, но даёт она только 20% результата. Однако без отладки невозможно 80% функциональных возможностей любой программы. Если вы хотите добится успеха, вы должны сначала добиться успеха в отладке."
В работе я пологаюсь на принципе логики Хоора - это привычка доведенная до автоматизма, как слепой ввод в любой современной клавиатуры. Вот и всё, что вы хотели узнать.
Весь прикол в том, что если в C/C++ ты сделал ошибку, то её так же легко и исправить. Да и далеко не часто делаешь серьёзные ошибки - чаще весь хайп вокруг уязвимостей построен на потенциальных уязвимостях, а не лабораторий ESET, Антивируса Касперского, Dr. Web и прочих институтах, которые целиком занимаются исследования компьютерных вирусов и хакерских атак.
Граждан тут слишком утрирует ситуацию, мол слишком много об уязвимостях говорят (нет, это ты слишком мало читаешь что-то ещё), и теперь я не могу доверять ни одному языку программирования. Отсюда и все дикости с переписыванием стандартной библиотеки и прочий бред.
Серьёзные люди такими дикостями не занимаются. Так же как и давно переросли в себе комплекс перфекциониста, и не ставят себе вопросом жизни и смерти задачу написать идеальную программу с первого раза.
Если мне нужно оптимизировать потоки и извлекать меньшие конфликты от ожиданий данных, то ещё с 2010-го года, со стандартами С11, С++11 есть атомарные операции.
Не говоря уже о том, что есть классические семафоры, мониторы и мьютексы, для особо критических случаев, помимо синхронизаций. Там порядочно добавили, на любой вкус.
Мне неинтересно решать задачки за других, ясно. Лучше киньте тогда что-то более полезное, например затык в полезном специфическом софте. Вот там помогу решить.
Да вы по всему топику о себе много рассказали. Языки вам какие-то не такие. Тестирование для него какое-то не такое. Отлаживать за 10 лет не научился, а скорее всего там и года не было.
Ещё и накидываетесь на других, мол, какие-то не такие. Руку сначала набейте в отладке, тогда и поймёте что вам даёт C, а следом C++.
Напоминает один очень меткий комментарий:
"Я не люблю C++, потому что он не позволяет мне писать говнокод".
Что сказать, в остроумие автору не занимать.
Сколько видел подобной критики, но ни одного конструктивного предложения в ответ.
Вы себя послушайте. Вся стандартная библиотека написана базовым синтаксисом языка, и представляет во многом обобщение раннего опыта разработчиков в рамках ещё C89, после дополненных в C99, и расширенных в С++ в 1998 году, и STL, на основе его же синтаксических конструкций, использующих самые продвинутые техники использования языка в 2002 году.
То что в них иногда обнаруживали выходы за границы массивов, переполнения регистров или краш из-за несовпадения последовательности (в данном случае процессор пытается обратиться к несуществующему адрессу) уже говорит о том, что сами современные программисты не соблюдают правила слишком часто, чем программисты поколением до них. Кому тут больше недоверия уже совсем другой вопрос.
А как ещё помочь человеку, который потерял веру в себя?
Посоветовать действовать решительней и не воспринимать неоконченную документацию как истину в последней инстанции? Или ещё изложить басню о том, что делать какие-то свои доработки, пусть и только в оформление - это вполне нормальная практика, и в ней нет ничего непристойного?
Я ещё в 2014-м отказался от этой практике на форумах, когда такой приём использовался только чтобы без слов сказать "сделайте всё за меня".
Обычно такие элементарных исходят из того, чтобы можно было только по одним именам функций и их параметров легко определить что они делают, в рамках объекта или модуля в целом.
Если вам этого не достаточно, то разберитесь с форматами данных, которые получаете, и которые выдаёте в конкретных функциях, и уже значительно легче будет понять что с ними делать.
У вас проявляются все симптомы сильного профессионального выгорания. Тут скорее поможет хороший психолог, чем мои консультации - только вы и люди, с которым вы непосредственно близко общаетесь, знают ваши настоящие мотивации, никто в Сети не сможет вам дать эффективный рецепт для работы над собой и повышения самооценки, не более чем намекнуть, надоумивают обычно либо близкие люди, либо друзья, либо коллеги, либо как раз психологи, которые придметно консультируют.
Изменения в нейминге сделают код значительно более удобочитабельным, что позволит проще понять его свежим взглядом. И следовательно проще будет найти алгоритмическую ошибку, приводящую к появлению высячих ссылок, утечек памяти и прочих подобных ситуаций.
Такие вещи самособойразумеющиеся и представляют элементарное здравомыслие при написание любой программы.
Например, логической привязки имён функций и переменных с внутренней логикой модуля, в котором они используются. Очень хорошо это отражено через имена стандартных функций и STL.
Не буду лгать. Очень трудно читать ваш код, он не сложен по структуре, а именно лишен всякой логики в связке с модулем.
Просили прокомментировать. Я полностью согласен с комментарием @shaykemelov от 4 января этого года, 2:53. Поработайте сначала над неймингами функций и переменных, чтобы они были логически связаны с модулем для которого рассчитаны.
На практике такие секреты, скорее обычные профессиональные привычки, которых у вас ещё нет.
Тут всё зависит от того, что подразумевается под ошибком в данном случае.
Умение видеть картину объемно вырабатывается ещё на первых курсах технических вузов. С другой стороны и гуманитариев обижать не стоит, профессионально это называется зуммирование, когда вы смотрите на ситуации не из момента "здесь и сейчас", а в более общем плане, чётко представляя что вы сделали до этого по сравнению с тем, что было до вас.
Если хотите инструментарии, то очень советую обратить внимание на более профессиональные программы трейсировки. На Хабре есть статья "24-ядерный CPU, а я не могу сдвинуть курсор", где наглядно представлена практика работы с такими программами. Я так же с этим работал, когда разбирал выбесшие меня "Системные прерывания" на планшете с Windows 10 - несколько минут в Google, предложили подобную программу от MSI, с помощью её понял, что ОС не могла запустить драйвер встроенной графики и конфликтовала с ним. Дальнейший путь меня привёл к тому, что оказалась проблема в сильно костыльном несовместимом UEFI (он был жестко завязан на Windows 8) - теперь ожидает, когда у меня появится снова программатор, чтобы уже окончательно разобраться с этой проблемой.
Всё очень просто. Доверие.
Когда вы пытаетесь искать везде только изъяны, то неизбежно становитесь заложником своих же предрассудков и постепенно, но неминуемо превращаетесь в параноика.
Программирование подобно течению. Для того чтобы подчинить его своей воли, нужно ему поддаться. И для начала перестать скрести по сусекам и выбрать что-то конкретно определенное.
Ваша самая большая ошибка, в том что вы исчите изъян в инструменте, когда вся ваша речь один большой синтез и не может иметь строго одного определения.
Воззразите: А что с этим делать?
Достаточно ответить только на один вопрос: "А что ожидают от программы, кроме того, чтобы она делала то что от неё требуется и не выводила из себя её пользователя?"
Что и называется, "работает без нареканий".
Здесь и отличие хорошего программиста от плохого. Хороший программист уже по привычке следует негласным правилам хорошего тона, плохой такой привычки ещё не имеет. Хорошо, когда хотя бы стремятся подражать, плохо - когда человек находит любое удобное объяснения своему равнодушию.
Тексты комментариев и статей во всём Интернете всегда одного цвета. Но это не мешает ориентироваться по заголовкам.
Когда же весь текст у тебя как Новогодняя Ёлка, украшенная довольно безвкусно, то это неизбежно утомляет при его чтение, а выделяет мало или зачастую там, где это не имеет смысла.
Такие вещи понимаешь из опыта, может кому-то это более интересно, поэтому я больше за кастомизацию плагинами, а не тупо "поставим пользователей перед фактом, у них всё равно нет другого выбора". Выбор есть всегда, нужно просто уметь его найти.
Удивительно, насколько дословно вы следуете договору. Даже юристы менее дословны, чем вы. Безумец. Словно это уже не договор, а священное писание.
Только если уж сильно интересует дословное прочтение, то почитайте Библию - там иногда очень много полезного и интересного записано.
Занимательно. Невозможно успеха в работе, если не умеешь расслабляться, с одной стороны. И при этом вы словно ничего не пытались изменить - с другой.
Тут уже скорее выбор инструментов под себя, нежели поиски каких-то "идеальных языков программирования", языки лишь способ изложения, программу создаёт уже компилятор.
Я не спорю, что именно вам полезны инструменты статического анализа, всё таки лучше всего они справляются именно с опечатками.
С другой стороны лучше уже привить себе привычку писать код разборчиво, чтобы его изначально было удобно читать. Тоже и касается и редактора кода - если бы мне пришлось работать только на Visual Studio, то как минимум в первую очередь я сделал плагин, который возвращает классическое выделение и напрочь убрал цветное выделение, кроме классического зелёного для препроцессора и директив компилятора и синего для значений констант. Наблюдать постоянную ЛГБТ-подсветку, которую ещё трудно отключить, во всём исходнике довольно утомительное удовольствие.
Жалкое зрелище здесь только вы. Всего хорошего.
Вы читать вообще умеете? Я предлагал адаптировать код, использовать наработки из прошлых проектов, а не публиковать. И никто публиковать это в свободный доступ тут не собирался.
Только вы одного не учитываете. Я беру кейсы на основе реальной практики, а не каких-то псевдофилософских предположений, как вы.
По одной вашей манере речи можно судить какой вы специалист. Вам бы уже давно только на этом основание указали на дверь. Может вы забыли, но мы говорим не о начинающих, а об уже сформировавшихся специалистах.
Я и без вас знаю, когда нужен сеньор, а когда прекрасно справится мидл. Ни у меня, ни у моих коллег нет традиции усложнять себе работу, спасибо.
Вряд ли в таком вообще возникнет необходимость. В инженерии, где я работаю, и в более зрелых коммерческих областях предпочитают опираться на более зрелые и документированные стандарты, нежели выдумывать велосипеды на каждый чих.
Да мне абсолютно всё равно, кто он здесь. Даже если он копипастил чужие мануалы по написанию драйверов, то это далеко ещё значит, что он сам написал хотя бы один реально рабочий драйвер.
Хатаб больше сделал для общества, чем ваш @0xd34df00d, который даже псевдоним человеческий не мог сочинить и прикрывается адрессацией.