У Вас есть хороший совет/ссылки ряду стандартов кодирования или лучших практик для следования?
blockquote>Наиболее важным фактором безопасности всегда является риск . Мы никогда не сможем создать совершенно безопасную систему, мы можем только попытаться сбалансировать стоимость атаки на систему и стоимость ее взлома. Поэтому прежде всего я хотел бы спросить: что представляет собой риск, если кто-то знает URL вашего API?
Вы правы - это минимальная форма безопасности. Просто не более того.
Задайте себе ряд вопросов:
Что может узнать злоумышленник по ответу? - если вам просто нужно знать, что что-то существует, чтобы начать получать ответы , вы можете начать тестировать его, чтобы увидеть, как он себя ведет. Вы можете помешать этому, подавив ВСЕ ответы, но это может негативно повлиять на ваших законных клиентов, поэтому вы спрашиваете ...
Могу ли я ограничить то, что злоумышленник может узнать по ответу? - если злоумышленнику требуется дополнительная информация, чтобы построить законный запрос , вы можете регулировать и ограничивать все легитимные запросы.
И вопросы продолжают расти оттуда. Все сводится к рентабельности инвестиций - какова ценность того, что вы защищаете, какова площадь атаки и какова вероятность того, что она будет нарушена? Самое главное - это доверие ваших клиентов и пользователей. Как профессионалы, мы должны защищать целостность информации, которой мы доверяем.
Отдельный вопрос по HTTPS (TLS / SSL), что защищено, а что нет, от сторонних слушателей? Краткий ответ: если вы запрашиваете
foo.com/bar, имя хоста (foo.com) видимо всем, кто хочет знать, но путь (/bar) - нет; и куки, заголовки и все остальное, включенное в запрос, является безопасным.
19 ответов
Google имеет отправленное руководство по стилю для C++ здесь, с которым я иногда консультируюсь. Просто прочтение объяснений и обоснования, несмотря на то, заканчиваете ли Вы тем, что согласились с некоторыми стилями или нет, может преподавать Вам некоторые вещи, о которых Вы, возможно, не думали.
Ответы здесь довольно полное, таким образом я не указываю на другой кодирующий стандартный документ. Однако, после того как Вы решили придерживаться одного стиля, необходимо использовать автоматизированное средство обеспечения выполнения стиля кодирования всюду по команде.
Для Java существует checkstyle и для.NET Microsoft Style Cop.
Вот подобное обсуждение Stackoverflow: стандарт Кодирования C# / Лучшие практики
Для C# я рекомендую Руководство по проектированию Платформы: Конвенции, Идиомы и Шаблоны для Допускающих повторное использование Библиотек.NET (2-й Выпуск) (Ряд Разработки Microsoft.NET).
я думаю Ремесло Кода - Практика Написания Превосходного Кода в значительной степени подводит итог всего этого
Это не вполне отвечает на вопрос, но это стоит упоминания...
Я прочитал Завершенный Код Steve McConnell. Пока это не дает Вам подвергнутый термообработке набор кодирования стандартов, это действительно излагает много хороших аргументов для различных подходов. Это заставит Вас думать о вещах, о которых Вы не думали прежде.
Это изменило мой небольшой мир к лучшему.
Для Java и других языков C-семейства я рекомендую стандарты кодирования Обезьяны Sofware (конечно, так как они являются моими).
В целом сохраните их простыми, и обеспечьте примеры и выравнивание для каждого требования.
То, что находится в стандарте, действительно не имеет значения все так очень. То, что имеет значение, - то, что Вы имеете один, и что Ваши разработчики следуют за ним.
Если Вы планируете представить форматирующий код стандарт существующей команде программистов, быть введенными от каждого члена команды, таким образом, они будут иметь, "покупают акции" и, более вероятно, напишут код к тому стандарту.
Стили программирования столь же трудно изменить как привычки, и необходимо будет признать, что некоторые люди не сделают свой код 100%-ми совместимыми 100% времени. Это стоило бы Вашего времени, чтобы найти (или записать Ваше собственное) программа симпатичного принтера и периодически выполняло бы весь Ваш код через него для осуществления непротиворечивости. (Я всегда чувствовал себя неловко при ручной регистрации в изменениях исходного кода, которые только состояли из форматирования исправлений для кода других народов; я волновался, что другие маркируют меня педантом.)
При поддержании кода, которые продолжают использовать тот же стандарт, как исходный код был разработан в (нет ничего худшего затем попытки отладить проблему, когда код смотрит весь higgildy piggeldy),
Некоторый комментарий к предложению сообщения, смотрящему на Google инструкции C++. Детальное обсуждение о некоторых аспектах этих инструкций отправляется в comp.lang.c ++. модерируемый.
Некоторые странные или спорные мнения включают:
Мы не полагаем, что доступные альтернативы исключениям, таким как коды ошибок и утверждения, представляют значительную нагрузку.
Как будто утверждения были жизнеспособной альтернативой... Утверждения обычно для программных ошибок и ситуаций, которых никогда не должно происходить, в то время как исключения могут произойти (несколько ожидаются) в потоке выполнения.
Ссылочные Аргументы: Все параметры, переданные ссылкой, должны быть маркированы константа... На самом деле это - очень сильная конвенция, что входные параметры являются значениями или ссылками константы, в то время как выходными аргументами являются указатели.
Никакой комментарий, о ласке формулируют очень сильную конвенцию.
Выполнение Работы в Конструкторах: Сделайте только тривиальную инициализацию в конструкторе. Если вообще возможный, используйте Init () метод для нетривиальной инициализации .... Если Ваш объект требует нетривиальной инициализации, считайте наличие явного Init () методом и/или добавлением членского флага, который указывает, был ли объект успешно инициализирован.
Да... 2-фазовый init для создания вещей более простыми... Что, если я имею const поля? Это правило является, вероятно, эффектом отношения к исключениям.
Используйте потоки только для входа
Какие потоки? IOStreams, стандарт C потоки, другой?
С одной стороны они советуют для использования макросов только в исключительных ситуациях, в то время как они рекомендуют использовать DISALLOW_COPY_AND_ASSIGN для запрещения, копируют/присваивают. Они, возможно, советовали подходу со специальным классом (как в Повышении)
Не перегружайте операторы кроме редких, особых обстоятельств.
Что относительно присвоения или арифметических операторов для числовых вычислений, и т.д.?
Параметры по умолчанию более трудно поддержать, потому что вставка copy-and-из предыдущего кода не может показать все параметры. Вставка Copy-and-сегментов кода может вызвать основные проблемы, когда параметры по умолчанию не подходят для нового кода.
Какой? Скопировать/вставить из предыдущего кода?
Помните, что чтение любой из инструкций может представить предвзятость Вашему образу мыслей. И иногда это не будет выгодно для Вас или Вашего кода. Я соглашаюсь с некоторым другим уведомлением сообщений, читая хорошие книги хороших авторов заранее. Когда у Вас есть достаточная сумма знания, затем Вы можете посмотреть на инструкции и найти положительные стороны и слабые места легко, не создавая путаницу в Вашем мозгу ;)
Кодирующие стандарты являются большими. Мы использовали Стандарты Кодирования C# Lance Hunt для.NET почти без модификаций
У Adam Cogan есть большой подшипник на его веб-сайте. Там кодируют инструкции, но существует намного больше там также.
Кодирующие стандарты хороши, но стандарты кодирования, записанные с нуля, в котором компания изобретает велосипед, или стандарты кодирования, наложенные единственным "пророком", могут быть хуже, чем наличие никаких стандартов кодирования вообще.
Это означает:
- Кодирование стандартов должно быть обсуждено и согласовано.
- Документ стандартов кодирования должен включать причины позади каждого правила.
- Кодирование стандартов должно по крайней мере частично быть основано на надежных источниках.
Источники, о которых я знаю для языков в Ваших тегах:
- Для C++: книга Стандарты Кодирования C++ Sutter/Alexandrescu.
- Для C#: 4 или 5 PDF я нашел поиск с помощью Google для Стандартов Кодирования C# :)
Задав этот вопрос. Я нашел, что принятый ответ оказался достаточным для моих потребностей.
Однако я понимаю, что это не 'единый' сценарий, таким образом, существует большое количество информации в потоке, который можно найти более или менее полезным. Weel, стоящий чтения!
Мой лучший совет относительно кодирования стандартов: не позволяйте им помешать при попытке получить сделанную работу.
Многочисленная бюрократия могла бы на самом деле препятствовать прогрессу проектов вместо того, чтобы помочь достигнуть лучшей работы в команде. Когда люди жалуются на не следование стандартам кодирования вместо фактического качества кода, затем это - слишком много регулирования.
Кроме этого, выберите один от многих предложений и попытки придерживаться его максимально долго для создания кодовой базы в соответствии с единственным стандартом, к которому Вы привыкли.
Сами стандарты кодирования великолепны и все такое, но то, что я думаю, намного, намного, НАМНОГО больше важно придерживаться стиля любого кода, который вы поддерживаете. Я видел, как люди добавляли функцию к классу, написанному одним способом, и навязывали свой стандарт кодирования только этой функции. Он непоследовательный, он выделяется и, на мой взгляд, затрудняет получение удовольствия от занятий «в целом».
Всякий раз, когда вы поддерживаете код, смотрите на код вокруг него. Посмотрите, что это за стиль. Подтяжки K&R? Методы Capital Camel Case? Венгерский язык? Блоки двухстрочных комментариев между каждой функцией? Как бы то ни было, вы должны сделать это и в этой конкретной области.
Прежде чем я уйду, я хотел бы отметить одну вещь, связанную с именами файлов. В основном я работаю на C ++, так что это может не относиться ни к чему другому, но в основном это _.h или .cpp. Итак, Foo :: Bar будет в Foo_Bar.h. Обычные вещи (например, предварительно скомпилированный заголовок) для пространства имен Foo будут в Foo_common.h (обратите внимание на общий нижний регистр). Конечно, это дело вкуса, но все, кто работал с этим, высказались за это.