Работал в одной компании, где code conventions предусматривали смешанное использование пробелов и табов. Долго воевал за пробелы, но аргумент от тимлида был — у каждого свои настройки табов, которые ему удобны, и мы должны уважить каждого. Достаточно сложно было контролировать правильную расстановку, но ничего не ехало. Но я все-таки предпочитаю пробелы, так как создавать самому себе лишние сложности в виде контроля расстановки табов и пробелов вместо сосредоточения на написании кода как такового — такое себе занятие.
Удобство разработчика это совершенно 10 дело. Первое, и единственно значимое, удобство пользователя. И когда разработчики перестанут об этом забывать, тогда и будет более качественное и функциональное ПО, а не 100500 слоёв красивых абстракций, которые тормозят на флагманском аппарате, на ровном месте. =)
Совершенно верно. Пример из другой отрасли: с логикой «должно быть удобно разработчику» можно дойти до того, что производители автомобилей не оставят ни одной педали, перенеся их на консоль, и сделают 2 квадратных колеса, потому что это удобнее производить и поддерживать.
Очень интересно будет посмотреть, как робот с ИИ будет общаться с 3-5 летним ребенком, у которого 100 «почему?» возникают в минуту. Как бы в процессе не исчерпались ресурсы :-)
Кстати, сейчас minidlna ставится из репозиториев прекрасно через apt-get и замечательно работает! Спасибо большое за статью! Поставил в виртуалбокс нативное приложение LG Smartshare — телевизор его не видит. С minidlna все заработало; линукс рулит :-)
1. Ну вот не хотят они уделять время для ревью, приходится по 5 раз тыкать палкой :)
2. Код заведомо соответствует PEP8. Под кодстайл, который может не понравится ревьюверу, я имею ввиду, например, названия переменных, внутренние соглашения компании и тд. Но при проверке их ревьюверы, как правило, уходят от сути задачи и упускают возможные ошибки в самом решении.
Пара вопросов по процессу разработки:
1) Как сделать так, чтобы коллеги достаточно быстро отсматривали ревью?
2) Как сделать так, чтобы коллеги сосредотачивались на том, насколько функционально правилен код, а не на code style? Так как, при отвлечении внимания на второе, очень высока вероятность пропустить проблемы в первом кейсе…
Второй READ COMMTITED
В данном случае прочитать данные возможно только после вызова COMMIT. При чем внутри транзакции данные тоже будут еще не доступны.
Пожалуйста, не вводите людей в заблуждение и исправьте текст статьи! Как говорил уважаемый StraNNikk, свои изменения всегда доступны внутри транзакции, до коммита.
Проявите снисходительность к новичку :) Я не думал, что есть смысл переводить этот псевдокод. Если попытаться представить его в другом формате — не будет ли это нарушением правил перевода? Если вы считаете, что перевод этих блоков улучшит статью — я буду только «за» сделать это.
Нет, конечно; это что-то вроде псевдокода. Если речь про то, что я указал язык «cpp» в хайлайтере — просто не удалось подобрать что-либо удобоваримое под эти блоки, а оставлять их совсем не расцвеченными не хотелось.
Не вполне понятна ваша мысль: вы имели ввиду, что "Нейронная оборона" совершенно непохожа на Летова или?..
Совершенно верно. Пример из другой отрасли: с логикой «должно быть удобно разработчику» можно дойти до того, что производители автомобилей не оставят ни одной педали, перенеся их на консоль, и сделают 2 квадратных колеса, потому что это удобнее производить и поддерживать.
По-моему, там чутка больше миллиона.
2. Код заведомо соответствует PEP8. Под кодстайл, который может не понравится ревьюверу, я имею ввиду, например, названия переменных, внутренние соглашения компании и тд. Но при проверке их ревьюверы, как правило, уходят от сути задачи и упускают возможные ошибки в самом решении.
1) Как сделать так, чтобы коллеги достаточно быстро отсматривали ревью?
2) Как сделать так, чтобы коллеги сосредотачивались на том, насколько функционально правилен код, а не на code style? Так как, при отвлечении внимания на второе, очень высока вероятность пропустить проблемы в первом кейсе…
Пожалуйста, не вводите людей в заблуждение и исправьте текст статьи! Как говорил уважаемый StraNNikk, свои изменения всегда доступны внутри транзакции, до коммита.