Какая практика программирования, которую Вы когда-то любили, имеет Вас, так как передумал о? [закрытый]

Prototyping in the IDE. Like all newbies I have learnt that jumping into the code is a bad idea. Now I tend to abandon silly ideas before even using a keyboard.

Требование, чтобы весь код был чистым кодом, даже если он уже работает.

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

• Время, потраченное на его очистку, не добавляет ценности продукту в то время, в то время как то же время, потраченное на отладку или разработку функций, действительно увеличивает ценность.
• ] Есть риск взломать уже работающий код. Никто не настолько удивителен, что никогда не вносит ошибок при рефакторинге. (Мне пришлось съесть скромный пирог, когда мои ошибки были доставлены заказчику.)

Конечно, если этот уродливый код требует новых функций, часто неплохо было бы его реорганизовать. Но в этом суть:

Некоторые:

• Начали использовать фигурные скобки в той же строке, а не на новой строке ( if (...) {)
• с использованием camelCase вместо of non_camel_case
• прекратил использовать printf () для отладки
• начал полагаться на сторонние библиотеки вместо того, чтобы писать каждый бит с нуля

jrh

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

Header files shall not include other header files.

I used to be strongly opposed to the idea of headers including other headers - based on a bad experience early in my engineering career. Having the headers included explicitly in the order needed right there in the source file seemed to work better.

Now - in general - I'm of the mindset that each header file shall be self-sufficient, i.e., not require other .h files to be included before it in the source file. Especially when developing in C++...

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

Кроме того, стиль объявления аргументов подпрограммы для длинного аргумента. список:
раньше

int foo (char arg1, int arg2, float arg3, double arg4)

сейчас

int
foo (
  char arg1,
  int arg2,
  float arg3,
  double arg4  )

это, конечно, дело вкуса.

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

Это то место, где я не согласен с советом моей собственной компании. Теория состоит в том, что вы должны перехватывать только те исключения, о которых знаете, поскольку у вас нет гарантии относительно того, что «плохое» произошло. Если память была повреждена или сама среда CLR застряла, вы не собираетесь восстанавливаться.

Однако, когда я работал над сервисами высокой доступности, я обнаружил, что часто бывали случаи, когда я хотел выразить «Поймай как можно больше ошибок. как можешь и продолжай ". Да, теоретически мы могли бы видеть исключения, с которыми мы не могли бы справиться, но с хорошо протестированным кодом в среде, которую вы контролируете (и с небольшим количеством собственного кода в смеси, кроме того, что предоставляет система), это оказалось лучшим вариантом, чем перехват только тех исключений, о которых вы знали.

Позиция команды CLR по этому поводу - «Не позволяйте вашему потоку выполняться в неизвестном состоянии», в то время как моя позиция - «Если вы знаете свой сценарий, это, вероятно, нормально». Возможно, это не нормально, если у вас есть веб-сайт банка, но в большинстве случаев это повысит вашу доступность и не заставит вас задуматься, почему ваше приложение перезапускается так часто.

Вы можете увидеть обе стороны дискуссии на http://blogs.msdn.com/clrteam/archive/2009/02/19/why-catch-exception-empty-catch-is-bad.aspx

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

/**
 * Returns the logger obj
 * @return log_Core
 */
public function getLogger() 
{ ... }

Теперь:

/**
 * @return log_Core
 */
public function getLogger() 
{ ... }

Конечно, хорошо названные функции помогают.

Создание хранимых процедур для доступа к данным. Ад поддерживать (особенно если вы разрабатываете на тестовом сервере и должны поддерживать другой сервер), и вы получите множество хранимых процедур, называемых NewInsertStoredProcedureLines, NewSelectStoredProcedureLines ... Теперь, когда он находится в жестком коде приложения, я счастлив отдыхать на природе.

The most significant change I've made is my approach to N-tier. I had been a believer in the separation of logic along physical tiers and building middle-tier "application servers". Going back to windows DNA using DCOM, MTS and COM+, then later on using .NET Remoting. At the time it had seemed reasonable from a security and scalability perspective to build systems this way. But having done it enough times to find that the added complexity (which is significant), network communication overhead, deployment issues, developer training, and the reality that security was never increased (because we never actually locked down firewalls between servers) has lead me to conclude that its seldom justified or warranted.

I'm still much in favor layering, and doing so in such a way as to allow tiering if it becomes a requirement, which I'm continuing to find, it seldom does.

Прямой доступ к базе данных.
В моем старом коде я широко использую запросы и наборы данных. Теперь я использую ORM для большинства вещей. Это дает мне более чистый код и лучшую возможность повторного использования. Обычно я теперь обращаюсь к базе данных только непосредственно в небольших программах или когда это необходимо для повышения производительности.

Возможно, что-то еще использует COM1 (программы автосинхронизации, как правило, довольно плохо захватывают COM-порты, как только они становятся доступными).

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

Небольшие компании могут обанкротиться, и у вас возникнут проблемы с обслуживанием вашей системы программного обеспечения в течение длительного периода. Возможно, «маленькое / инди» программное обеспечение сделает свою работу, но вы не можете быть уверены, что оно будет поддержано в следующем году.

Я много раз видел, как компания-производитель программного обеспечения (даже более крупная) разоряется, а вы внезапно возникнут проблемы с получением поддержки и / или разработчиков (по разумной цене) на рынке для вашей программной системы.

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

---

ДВА: Язык программного обеспечения / концепция / система X - единственный правильный способ делать что-то.

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

В заключение: Пусть это будет просто, глупо работает. Во многих случаях простое (даже «грубое») решение лучше, чем сложное (но «более приятное»). Используйте инструменты, лучше всего подходящие для ситуации, а не фиксированную мантру.

TDD и модульные тесты в целом. В какой-то момент я был сторонником TDD на своем рабочем месте, но со временем я узнал, что это действительно ничего не дает, по крайней мере, со статически типизированным языком.

Не поймите меня неправильно, я все еще считаю автоматизированный функциональные тесты очень важны.

Компактный код.

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

После необходимости поддерживать код Когда мне было несколько лет, я понял, что сокращение количества строк просто сделало код менее читаемым, а использование ярлыков привело только к неприятностям!

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

Кроме того, комментарии к коду имеют тенденцию не синхронизироваться с реальным кодом, который они должны описывать. Процитирую дядюшки: «правда в коде, а не в комментариях».

Настоятельно рекомендуемая книга: Чистый код: руководство по гибкому разработке программного обеспечения

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

Когда я впервые начал программировать, я быстро принял идею, что подробные комментарии бесполезны, и что вместо этого код должен быть написан таким образом, чтобы описать себя. Затем я довел это до крайности, когда я никогда не стал комментировать код. Иногда это хорошо работает для кода, представляющего бизнес-домен, потому что подробная документация должна быть где-то еще (например, DSL или документ), а значения членов класса очевидны. Однако при разработке более «рамочного» кода становится все труднее понять смысл. Это верно в отношении меня, оглядывающегося на свой собственный код, не говоря уже о других, которым необходимо его использовать. Я, конечно, использую комментарии для классов .NET Framework и других фреймворков, почему бы и нет? t Я пишу их для собственных фреймворков? Обычно я комментирую классы или методы только в том случае, если они имеют неочевидные характеристики или определенные зависимости от параметров и имеют особые типы поведения.

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Например, DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

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

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Таких как DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

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

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Например, DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

или иметь определенные зависимости от параметров и иметь особые типы поведения.

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Таких как DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

или имеют определенные зависимости от параметров и особые типы поведения.

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Например DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Таких как DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

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

Фактически, в диапазоне от отсутствия комментариев к эссе для каждого блока кода я постепенно ушел от без комментариев , к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Таких как DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

Я постепенно отказался от комментариев к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Например, DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

Я постепенно отказался от комментариев к разумному и эффективному их использованию. В будущем, когда сам язык позволит объявлять больше правил, вариантов использования и т. Д., Например, DbC, больше использовать выражения вместо операторов, потребность в комментариях уменьшится еще больше. А пока комментарии остаются полезными.

Никакого дублирования / повторного использования кода Я влюбился в это большое время. Дублирование - это нормально, если оно создает меньше работы, чем работа, необходимая для удаления дублирования. В некотором смысле это своего рода излишняя архитектура.

Используется при передаче целого числа функции format (). Детали ускользают от меня, так как я не могу понять, что именно является аргументом.

О, и это работает только тогда, когда целое является единственным аргументом. Если передать кортеж в формат, то будет вызван кортеж. __ format __ функция, а int. __ str __ или что-то в этом роде.

'{0}'.format(4)
str(4.__format__(format_spec=''))

-121--4950645-

Не помещайте ничего в корзину самостоятельно. bin является целевой папкой для двоичных файлов - она не является исходной папкой для двоичных файлов.

Создайте себе папку lib или что-то подобное, чтобы поместить ваши сторонние двоичные файлы. Вы можете даже назвать его «Сторонние двоичные файлы», так как не все знают, что «lib» означает одно и то же. Создайте ссылки на двоичные файлы в этой папке, и Visual Studio при необходимости скопирует их в bin (в том числе при перестроении).

-121--2741918-

Написание моего кода на испанском языке