Переносы строк вообще исчезают после сжатия.
Так что тут вопрос стиля кодирования. Если после точки с запятой всегда идет новая строка — проблем не будет.
P.S. Гуру JavaScript'а, поправьте меня, если я не прав.
Единственное, необходимо добавить, что в данном подходе необходимо иметь несколько «резервных» коннектов для выполнения таких вот операций с двумя коннектами. Так что, ИМХО, в высоконагруженной системе имеет смысл подумать еще раз, прежде чем использовать отдельный коннект.
1. Предельно аккуратно используйте:
1.1. Прямую работу с памятью и указателями.
1.2. Неявные приведения типов.
1.3. Переопределения операций.
1.4. Множественное наследование.
1.5. Сторонние библиотеки.
ИМХО, очень много пунктов…
Я, конечно, уважаю гуру плюсов, но лично мне кажется, что без анализотаров кода работать с такими потенциальными дырами = копать себе яму. Особенно при наличии в команде Junior'ов…
Иногда бизнес-логикой приложения почему-то начинают называть то, чего хочет видеть клиент, т.е. в первую очередь правила отображения. Из-за этого, в основном, и идет путаница.
Я за то, чтобы требования клиента так и называть требованиями, а не бизнес-логикой. Тогда все будет на своих местах.
Большая связность — хорошо для одного-пяти классов в пределах одного пакета. Эти классы часто имеют общий префикс или суффикс в имени, подчеркивая их связность.
Если же большая связность наблюдается для более пяти классов, то, как правило, имеет смысл разветвить их на две (или больше) группы.
Думаю, стоит использовать более корректную терминологию.
Бизнес-логику, конечно, иначе уже не назовешь, прижилось.
А вот логику представления и логику работы с БД можно назвать иначе.
В случае view это, конечно, тоже логика, но в первую очередь это отображение. Поэтому имеет смысл называть это «правилами отображения». Более того, это согласуется с термином «правила диспетчеризации» (dispatching rules).
В случае БД это запросы и структурирование результата. Поэтому можно назвать это «запросами», как правило низкоуровневую работу с БД на уровне запросов так и называют.
В данном случае, ИМХО, имеется в виду именно первичная разработка.
И еще если новая строка ставится только после точки с запятой или египетских скобок.
Так что тут вопрос стиля кодирования. Если после точки с запятой всегда идет новая строка — проблем не будет.
P.S. Гуру JavaScript'а, поправьте меня, если я не прав.
Как ни крути, если что-либо может быть понятно неправильно — оно будет понято неправильно ©.
Если же вначале кое-как написать прототип, то внедрить туда TDD становится нереально.
Но пока что ничего лучшего элита не придумала.
1.1. Прямую работу с памятью и указателями.
1.2. Неявные приведения типов.
1.3. Переопределения операций.
1.4. Множественное наследование.
1.5. Сторонние библиотеки.
ИМХО, очень много пунктов…
Я, конечно, уважаю гуру плюсов, но лично мне кажется, что без анализотаров кода работать с такими потенциальными дырами = копать себе яму. Особенно при наличии в команде Junior'ов…
И не панацея, есс-но.
Теперь в дело пойдут авто.
Вот только энтузиастов-максималистов пока что-то не видно.
Я за то, чтобы требования клиента так и называть требованиями, а не бизнес-логикой. Тогда все будет на своих местах.
Большая связность — хорошо для одного-пяти классов в пределах одного пакета. Эти классы часто имеют общий префикс или суффикс в имени, подчеркивая их связность.
Если же большая связность наблюдается для более пяти классов, то, как правило, имеет смысл разветвить их на две (или больше) группы.
Бизнес-логику, конечно, иначе уже не назовешь, прижилось.
А вот логику представления и логику работы с БД можно назвать иначе.
В случае view это, конечно, тоже логика, но в первую очередь это отображение. Поэтому имеет смысл называть это «правилами отображения». Более того, это согласуется с термином «правила диспетчеризации» (dispatching rules).
В случае БД это запросы и структурирование результата. Поэтому можно назвать это «запросами», как правило низкоуровневую работу с БД на уровне запросов так и называют.