Комментарии 32
«Во время работы незрячие программисты не пользуются выравниванием кода. Вообще. Мы расставляем все отступы уже после написания программы, для тех, кто будет работать с ней визуально»
Ерунда полная. Потом вот от таких нескольких людей формируется мнение о всех незрячих. Ерунда полнейшая, у каждого индивидуально. Я вот пишу на python, и всегда использую отступы,, да и на C++ использую, да и на php с html использую, с ними гораздо проще следить за уровнями блоков, чем разбираться в каше к какому блоку принадлежит та или иная строчка. И тот пример с чтением тоже ерунда. мало кто так использует скринридер, чтобы он читал абсолютно каждый символ. чтение таких символов как скобки, фигурные скобки, двоеточие и прочие не нужно. И так понятно где они стоят. А когда нужно проверить именно конкретный символ то только его и смотрят, а читать все время все символы ерунда. Ну и с пробелами тоже ерунда. В итоге несколько публичных незрячих программистов вводят в заблуждение зрячих людей о манере работы всех незрячих программистов.
А самое интересное, что одни и те же заблуждения переходят из одной статьи в другую.
В невизуальном режиме код можно отлаживать кучей способов. Вот как, например, у меня это происходит:
- Простой запуск кода, пока не получишь нужный результат.
- Тесты. Юнит, функциональные и т.п.
- Ошибки, выводимые статическим анализом + компилятором в зависимости от языка.
- Синтаксические ошибки может и ide подсказать.
- Дебагер. Лично я для php пока xdebug так и не освоил. Всегда хватало функции dd плюс все предыдущее. К тому же есть сомнения, что xdebug заведется на связке PHPStorm + wsl2 + docker. Но я надеюсь, что в обозримое время устраню этот пробел. :)
Я говорил скорее об анализе типов. В статически типизированных языках, как правило, этим занимается компилятор. А для моего основного php можно прицепить статический анализатор, который еще на стадии CI запретит передавать int в строковый аргумент и вызывать метод на nullable значении. :) Это дает дополнительные гарантии, хоть и требует чуть более кропотливого написание кода.
А вообще, если честно, я в том числе уже с трудом представляю разработку проекта и без тестов. Те же функциональные тесты чаще всего немногословны и при этом покрывают основную часть возможностей системы. Так что такие дополнительные инструменты бывают очень полезны, особенно на длинной дистанции.
Не знаю, разрабатываете ли вы один или в команде. Для хотя бы средних кодовых баз, где ты писал только часть, типизация помогает быстро понять, что принимает и возвращает метод. Плюс отловить какие-то базовые ошибки. В php почти во всех библиотеках указаны типы. Даже когда сам язык не позволял делать это нативно, типы аргументов прописывали в комментах к функции. Плюс в статическом анализаторе можно выставить уровень строгости. Например, для моего текущего проекта я выставил его на 3. Т.к. при 2 он уже требовал, чтобы все поля класса без дефолтных значений инициализировались через конструктор, на что мы пока не готовы.
Я работаю с докер в ubuntu, установленной на wsl2. Вообще в докере можно много чего накрутить, что потом будет плохо переноситься. Но мб и вам такая связка подойдет. Или дело не в разности системы.
Что поделать, если у современных разработчиков консольные редакторы вызывают священный ужас, а название Vim у них ассоциируется со средством для мытья посуды»
Многие любят Vi/Vim, без всяких священных ужасов.
Работая вместе с другими программистами, я частенько замечал, что у меня процесс написания кода идет куда быстрее, чем у коллег. В немалой степени это происходит потому, что я многое держу в голове, и мне не нужно постоянно проверять данные.
Хорошие программисты всегда погружаются в работу и держат все в голове. Без этого они не смогли бы стать хорошими программистами.
Кроме того, с таким приложением гораздо труднее допустить опечатку: программа четко озвучивает все вводимые символы и не дает перепутать кириллическую «с» с английской «си» или одинарную кавычку с апострофом».
IMHO опечатки — это уже на уровне тактильной работы с клавиатурой. Кроме того, при слепой печати, ты всегда смотришь на экран и сразу все видишь.
Поддержу. Отступы в коде — это де-факто отраслевой стандарт. Их чтение я, например, обычно выключаю. Но при дебаге или работе с yaml или python возвращаю обратно. И озвучиваются они либо звуковым сигналом, высота которого зависит от уровня вложенности, либо сообщением вроде "4 spaces, 2 tabs" и только при переходе на другой уровень вложенности. Так что оно почти не мешает.
Это перевод?
Это компиляция нескольких статей, плюс мб что-то от себя. Многое взято отсюда
Не знаю, как было раньше, но сейчас продукты jetbrains вполне хорошо доступны.
Про Mac и VoiceOver — как и для зрячих — сплошная вкусовщина. Я на маке с VoiceOver программирую C/C++, Objective-C, Swift, Java, Python… Про IDE от JB— просто ложь, всё там норм с A11y.
Сложно поверить, однако это есть здесь и сейчас. Казалось бы что может связать слепого с программированием?? Ответ прост - болшое желание заниматься любимым делом и помогать людям.
Мы работаем во тьме: кодинг «глазами» незрячих программистов