Страницы

Поиск по вопросам

Показаны сообщения с ярлыком стиль. Показать все сообщения
Показаны сообщения с ярлыком стиль. Показать все сообщения

среда, 22 января 2020 г.

Python. Стиль программирования

#python #стиль


Вопрос очень начального уровня, но интересно мнение со стороны, и возможно советы. 

В данный момент я учусь создавать GUI вручную. Появилась одна проблема: после Java
привык все называть переменные в CamelCase стиле и давать очень подробные имена (издержка
неумения). 

К примеру, есть ссылочка на виджет, который представляет собой панель для управлением
stack layout (в нем лежат так называемые рабочие модули), и он делает один из рабочих
модулей "активным". 

Ранее называлось все это безобразие у меня activeWorkingModuleControlPanel. Тут я
почитал PEP8 и внес коррективы, но не уверен, правильно ли, и улучшил ли я что-то: 

#WM - working modules
...
panel_control_wm

тип виджета_что делает_над чем делает


Хочу разобраться в стилях наименования. Если есть какие-то статьи, в которых были
бы разобраны различные варианты, с ПОДРОБНЫМ практическим применением в сложных случаях
(когда имя ссылочки должно быть информативным в связи со сложностью системы)?
    


Ответы

Ответ 1



Если вы пишете код и в чем-то не уверены, что следуете стандарту - поставьте пакет pep8 - http://pypi.python.org/pypi/pep8. В нем есть скрипт, который указывает на несоответствия стандарту.

Ответ 2



Вставлю и я свои пять копеек. На самом деле, все зависит от того, как вы договоритесь с командой и кто ваш проект может поддерживать. И camelCase никакой не пережиток. Всегда более-менее придерживался PEP8, но однажды пришел в большой сложный проект, связанный с ИИ и data mining, который начали и вели бывшие Cишники, т.к. ядро переписывалось с С++ на Python. Все и везде в стиле camelCase, особо хардкорные дяди условия в скобочки оборачивали:) Абсолютно ничего страшного, тут все в дело в том, чтобы все участники использовали одинаковый стиль кода. Даже поймал себя на мысли, что camelCase часто более понятен, чем_вот_такие_вот_супер_длинные_названия Ну и потом, слепо следовать PEP8, наверное, немного глупо. Ну многие ли следуют ограничению в 79 символов в строке? Это актуально для тех, кто пишет для переферийных устройств. Для разработчика под ОС, и, тем более, под веб это нецелесообразно. Мониторы-то у подавляющего большинства больше, чем 19'' :)

Ответ 3



Не совсем ответ на вопрос, однако, вас, например, может заинтересовать Google Python Style Guide в роли некоторой альтернативы PEP8. Лично мой процесс привыкания к этом стилю прошел совершенно безболезненно и быстро.

воскресенье, 29 декабря 2019 г.

Функции С в C++

#cpp #стиль


Возможно, некоторые помнят мой вопрос-просьбу сделать ревизию кода по заданноу тех.
заданию.
Собственно, код весьма справедливо раскритиковали, назвали его плохой смесью Си с
Си++, что код обладает плохой структурированностью и т.д. и т.п.
Я со всем этим согласен.
Но у меня возникает справедливый вопрос, о том, собственно говоря, как же избегать
кода Си в программах на С++, ведь, полностью от кода Си, по-сути, избавиться то невозможно.
Ведь все равно так или иначе нужны будут функции из стандартной библиотеки Си, вроде
тех же memcpy или strncpy, указатели на буферы из чаров (хотя все это дело можно и
даже нужно инкапсулировать в класс строк), и т.п. и т.д.
В принципе, после чтения Прата, уже сложились кое-какие (весьма скромные) представления
о том, как же все-таки должен выглядеть код на C++, но тем не менее.
Например, мне нужно скопировать один кусок памяти в другую область памяти.
Писать для этого отдельный класс, а-ля CopyFactory, который будут хранить указатели
на все нужные буферы, определять все необходимые конструкторы и операции, конструктор
копирования и оператор присваивания, либо же, для экономии времени, все-таки достаточно
будет какого-нибудь smart_ptr с memcpy?
Понимаю что все это относится больше к стилю кода, и каждый пишет програмы по-разному,
но тем не менее, есть же наверняка какие-то стандарты либо правила?
    


Ответы

Ответ 1



Если сильно нужны именно Сишные функции — используйте. Только не подключайте Сишные заголовочные файлы, используйте стандартные обертки для них (вместо math.h, например cmath) для более корректной совместимости с C++; если это нестандартные Сишные функции — оберните сами их в extern "C". Если неясно зачем всё это — попробуйте собрать такой код: #include #include #include using namespace std; int main() { float a = 1.2; cout << abs(a) << endl; return 0; } Затем тоже самое, но с заменой первых двух строчек на следующее: #include #include и разберитесь почему поведение программ разное.

Ответ 2



Например, мне нужно скопировать один кусок памяти в другую область памяти Не работайте с памятью как с "памятью", работайте с ней как с набором элементов. Элементы эти помещайте в контейнер, у контейнера вызывайте операции копирования. Дальше это уже дело контейнера как их копировать - через memcpy как POD типы или через операции копирования в противном случае.

Ответ 3



При хорошем стиле можно почти полностью избавиться от любых проявлений C: не работать с памятью напрямую, использовать интеллктуальные указатели. А если вам нужно получить доступ к памяти напрямую, то, ИМХО, лучше написать класс-помощник, чтобы не жалеть потом о времени, потраченном на отладку. В частности, использование char*, как нечто большее, чем временный буфер для API функций и др., нехорошо, т.к. есть переносимый класс string, являющийся частью Стандарта.

Ответ 4



Хочу примеров. В остальном, как правильно заметили остальные отвечающие, у ТС проблемы с переходом от одной модели программирования к другой. Я лично не понимаю зачем использовать ф-ции strcpy и пр., если можно использовать прекрасный тип std::string. Безопасно и надежно. При необходимости std::string всегда можно сконвертировать к "старым добрым" Сишным строкам, а потом наоборот из Сишной строки его сконструировать. Единственное, что вызовы старого API будут обрамлены жутковато выглядящим кодом преобразования. Но что поделать? Касательно работы с памятью - вообще не понял зачем она тут нужна.

вторник, 24 декабря 2019 г.

Как вы отделяете код от представления?

#php #стиль


Как вы отделяете код от представления (например от html) в больших проектах?

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

Лично я формирую массивы данных в контроллере и через функцию произвожу подключение
.tpl файла, в функцию передаю массив данных, а функция возвращает буферизированное
решение этого файла. В самом файле нужный контент (html, xml, json...) с php вставками
переменных вроде: 



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

Допустимо ли с точки зрения идеологии MVC в таких файлах шаблонов производить подключение
шаблонов напрямую? Не важно в цикле или чем-нибудь вроде View::renderMatch('short/article.php',
$data['articles_data_array'])

Не затрагивает ли такой сбор шаблона обязанности контроллера? Вопрос не обязательный
для ответа.

Главный вопрос в том, как вы отделяете в своих проектах логику представления, от
шаблона и делаете ли это вообще. Было бы интересно почитать как это делают другие люди.
    


Ответы

Ответ 1



Другие люди используют шаблонные движки. Хоть Smarty, хоть Liquid, хоть Mustache, хоть Twig или Blade. Все сколько-нибудь серьёзные шаблонные движки умеют подключать шаблоны внутри шаблонов, наследовать шаблоны от других, и так далее. В общем случае вы можете ожидать примерно одного уровня возможностей. Выбор шаблонного движка - дело вкуса, предпочтений и традиций в вашей среде (разработчики под Laravel пользуются Blade, а Symfony - Twig). Бонусом к использованию шаблонного движка вы получите и защиту от случайных XSS, и более чистый код без бесконечных проверок isset(), и возможность делегировать работу над вёрсткой страниц посторонним. Шаблонные движки приводят к некоторому замедлению открытия страниц при первой компиляции шаблона, но эта проблема решается массовой компиляцией шаблонов при деплое.

Ответ 2



Обычно есть контроллеры, которые собирают данные для представления (виды), и, если надо, запускают валидацию введенных данных. Модели содержат логику по получению данных из БД и т.д., контроллеры используют методы моделей и не лезут в БД самостоятельно. Виды занимаются только формированием окончательного HTML. Никакой сложной логики, никакого обращения в БД. Как правило есть привилегированный вид - макет (layout), который содержит общий код для ХТМЛ страниц и в определенное место которого вставляется результат обработки вида. Виды могут вызвать вставку других видов - небольшие общие куски для нескольких страниц. Файлы видов располагаются в отдельной директории, в подпапке с именем контроллера и их имя соответствует имени метода контроллера.

воскресенье, 22 декабря 2019 г.

Где объявлять вспомогательные функции?

#cpp #ооп #code_style #стиль #оформление


К примеру, у меня есть класс, который делает WMI запросы, там часто надо преобразовывать
QString к BSTR, поэтому я хочу написать функции преобразования.
Где мне их лучше объявлять, в этом же классе, если да, то private или public? Создать
namespace с двумя функциями только для этого класса? Создать общий namespace для всех
функций преобразования, и, пока что, записать туда только две эти функции? Объявить
их глобально в хедере этого класса?
    


Ответы

Ответ 1



Как пишет Скотт Мейерс в своей книге «Эффективное использование C++»: Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса. Это повышает степень инкапсуляции и расширяемость, а также гибкость упаковки функциональности. Если хотите ознакомиться с этим правилом детальнее - см. стр. 105 вышеупомянутой книги. Если Ваши функции выполняют преобразование и не требуют доступа к закрытам данным-членам или методам Вашего класса - пользуйтесь этим советом, поскольку, если свободная функция способна обеспечить ту же функциональность, что и метод класса, то предпочтительней является свободная функция, поскольку она увеличивает степень инкапсуляции данных. А это уже одна из особенностей, ожидаемых от ООП программ. Идея использовать namespace, в который Вы поместите свой класс и эти функции преобразования, хорошая, явно лучше, чем подвесить их в глобальной области видимости.

воскресенье, 15 декабря 2019 г.

CSS height в % не работает?

#html #вёрстка #css #стиль


Почему, когда в height пишешь в px всё нормально, а когда в процентах, как на рисунке,
ничего не работает?
height в процентах нельзя делать?



    
        
        
        
        
        School.ua
    
    
        


Ответы

Ответ 1



Если вы берете проценты, их нужно брать от чего то Т.е. либо пропишите, как сказано выше body, html{height:100%} либо укажите в родительском элементе тоже самое body.style_body { height:100%}

Ответ 2



Конечно 100% можно использовать, но я бы вам советовал использовать так называемые viewport меры. (vh, vw, vmin, vmax) body { margin:0; } div { background: #0af; height:100vh; color:white; font-size:40px; text-align:center; }
100 высота


Ответ 3



Не хватает только прописать body, html{height:100%}.

Ответ 4



Стереть можно, у меня так получилось.

воскресенье, 1 декабря 2019 г.

Где найти хороший код? [закрыт]

#cpp #стиль


Хочу научиться читать чужой код. многие советуют начинать с хорошего кода.
во первых это легче, во вторых можно почерпнуть для себя много нового-как писать
хороший код. 
я столкнулся с такой проблемой-трудно найти хороший код.
во первых хороший код теряется в множестве плохих, а во вторых мне-начинающему программисту
 сложно отличить действительно хороший код от не пойми чего.
где можно найти действительно хороший код??    


Ответы

Ответ 1



Если речь идет только C++, то я бы лично смотрел в сторону гугловских opensource проектов, поскольку такой код однозначно требует таланта: Protocol Buffers Chromium gperftools googletest google-glog Также крайне рекомендую читать код Qt.

Ответ 2



Советую почитать дядюшку Боба "Чистый код. Создание, анализ и рефакторинг". Ну или хотябы 17 главу "Запахи и эвристические правила", чтобы отличать хороший код от индусского (:

Ответ 3



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

суббота, 30 ноября 2019 г.

Использование Си в C++ программах : все за и против [закрыт]

#c #c++ #стиль


Нужно ли воспринимать возможность использовать Си в программах на С++, как приятное
дополнение или относится только как к обратной совместимости?

Есть те, кто считает, что такое использование вредит пониманию, так как другой человек
может быть не знаком с некоторыми частями Си или вовсе не знать ничего, кроме С++.
Также некоторые считают это плохим стилем, потому что его использование делает код
не красивым. Или же с точки зрения убеждений, что код должен содержать конструкции
языка, на котором пишешь, а не смешивание new с malloc т.п.
Но а как же быстродействие некоторых его частей или использование удобных функций
форматирования?
Где та грань, которой нужно придерживаться?

Я описал только малую часть, так как на большее не хватает знаний. По этому было
бы прекрасно, если бы вы ответили не точно следуя этим вопросам, а опираясь на свой
опыт и мнение и этим возможно тема раскроется ещё глубже, что в дальнейшем поможет
и мне и возможно вам или кому-то другому.
UPD:
@avp, на материал во второй ссылке буду постепенно поглядывать, но скорей для справки,
чем искать повод для переезда на другой язык. Потому как в принципе я согласен со многим,
даже при том, что у меня очень мало опыта. Мне кажется, что если начинать с С++, то
это скорей будет изучение самого С++, а потом уже возможно через пару лет и программирования,
что нельзя сказать про Си, так как он действительно прост в понимании, особенно после
С++. И концентрация идет не на разбирание граблей языка или умения работать с stl/boost,
а на освоение новых алгоритмов при написании своих костылей. Такие костыли будут в
начале плохими и некрасивыми и на них будет уходить много времени в сравнении с использованием
готовых решений на C++, но их написание даст понимание как это работает или как это
выгодно модифицировать для своих нужд, а не просто использовать STL и даже может разбираться
частично как работают его внутренности, но все ровно не быть способным написать что-то
подобное на том же языке или другом.

Насчет первой ссылки, то встречал подобное и от самого автора(если не фейк) тут и
должен сказать на том этапе знакомства с С++, меня это довольно сильно расстроило,
так как неважно с какой целью началось изучения языка, но если видишь такое от его
создателя, то это не может не задеть.

Наверное я бы выбрал Си, если бы вернулся в прошлое, но сейчас буду и дальше продолжать
кодить с упором на С++ и поглядывать на С, то есть бежать наверх в низ по ступенькам.
Потому что во мне преобладает непостоянность и я просто обязан закончить с этой книгой).
Вот такие пироги.

P.S. Спасибо за ответы и приношу извинения, если развел здесь оффтоп.    


Ответы

Ответ 1



На самом деле, единой точки зрения на это нету. С одной стороны, С — очень мощное подмножество языка, и используя его, можно легко «прострелить себе ногу», то есть, наделать глупых ошибок по незнанию. Например, при помощи макросов можно сделать как много полезного, так и много вредного наподобие #define strcpy(a,b) memmove(a,b,strlen(b)+2), поэтому во многих проектах макросов стараются избегать — тем более, что при помощи гораздо более безопасных темплейтов можно сделать многое из того, что умеют макросы (и кроме того многое другое). Другими частыми источниками ошибок являются смешивание malloc/free и new/delete/delete[] (по стандарту, free(new int) есть undefined behaviour), ручное управление памятью вместо использования смарт-указателей и RAII (источник 90% проблем новичков на ХК), использование массивов (и более продвинутое велосипедостроительство) вместо подходящих стандартных контейнеров std::vector, std::map, std::stack (источник остальных 90% проблем новичков). Особенно сложно даётся новичкам работа со строками (которая, нужно признать, в C организовано не блестяще): немногие осилят правильное чтение строки не известного заранее размера из файла! С другой стороны, многие очень приятные лаконичные конструкции C не имеют прямого «безопасного» C++-варианта, например, обсуждавшийся недавно sscanf. Не стоит забывать, что C — другой язык, с другой идеологией, методологией и эстетикой, поэтому смесь кода на двух языках выглядит ненатурально и является источником ошибок. Например, в C приветствуются лаконичные конструкции: void copy_str(char *p, char *q) { while (*q++ = *p++) ; } — в то время как в рамках C++ этот код слишком плотный, чересчур завязан на конкретные типы, слишком прямо работает с памятью и и слишком надеется на непроверяемые предусловия (априори считается, что q указывает на выделенный кусок памяти размером не менее strlen(p) + 1). Для себя я установил правило: если пишется код на C++, стараться использовать идиоматичные конструкции, чтобы тем, кто читает мой код, было легче понимать его, и чтобы уменьшить вероятность ошибки: если выбран язык C++, а не C, надёжность более важна, чем экономия нескольких тактов процессора. Если же в каком-то месте я вижу необходимость использовать конструкцию из C, я пишу комментарий, обосновывающий эту необходимость. В любом случае, присоединяясь к существующему проекту на C++, узнайте, какие там стандарты на использование конструкций чистого C, и следуйте им. Update (спасибо @alexlz за комментарий!) Заметьте, что в случае ограниченности ресурсов (программирование для контроллеров, например), использование «полноценного» C++ может быть неоправданно затратным. Это усугубляется тем, что компиляторы для таких платформ зачастую выдают плохо оптимизированный код. В таких случаях распространённой практикой является отказ от всего множества языковых фич C++ и ограничение определённым подмножеством. Например, могут быть выброшены лямбды, шаблоны, стандартные контейнеры, исключения, стандартные алгоритмы, введено ручное управление памятью, то есть, итоговый язык будет ближе к чистому C. Но это — не от хорошей жизни (высокоуровневые конструкции позволяют забыть о надоедливых мелочах), и определяется опытным в разработке на данной платформе архитектором проекта.

Ответ 2



@strol, программирование само по себе достаточно сложная штука. Язык должен помогать как можно проще и естественней выражать свои мысли. На самом деле С++ язык сложный (а ведь создавался с целью упростить программирование на Си). Поэтому старайтесь писать проще (однако, не проще, чем необходимо) и не слишком переживайте по поводу смешения стилей. Конечно, некоторые вещи, которые на первый взгляд эквивалентны, могут на самом деле оказаться несовместимыми (например, new/delete и malloc/free). Просто о них надо знать, т.е. понимать как реализуются разные конструкции. В самом С++ полно взаимозависимых вещей и добавление чего-то из чистого Си ситуацию не упрощает (но и далеко не всегда усложняет). Примерно на эту тему мне понравилось высказывание Кернигана (кстати, они работали с Страуструпом в Bell labs) в интервью из книги "Пионеры программирования" ...Си занимает прочную позицию среди языков программирования. Он чрезвычайно выразителен, но в то же время не слишком сложен или велик, а кроме того, написанные на нем программы эффективны. ... С этим языком удобно работать, потому что если нужно что-то выразить, он представляет для этого не так много разных способов. Я посмотрю на ваш код и скажу: да, мне понятно, что он делает. Едва ли то же самое можно сказать о таких языках, как Perl или С++. Я посмотрю на ваш код и останусь в недоумении, потому что тут есть много способов написать одно и то же. C++ сложен и огромен, и выразить что-либо можно многими способами. Если мы с вами будем писать на C++, то можем прийти к весьма разным способам описания какой-нибудь большой задачи. В Си такого не бывает. Си сохранился потому, что у него оказалось хорошее соотношение выразительности и эффективности, и для важных приложений он остается лучшим инструментом. .... Бьерн голову себе сломал, пытаясь добиться максимальной совместимости с Си. Одной из причин успеха C++ в сравнении с другими языками была хорошая совместимость на уровне как исходного, так и объектного кода, а это означало отсутствие необходимости полностью перестраивать работу, чтобы использовать C++ в среде Си. .... Одним из крупнейших прегрешений считают чрезмерную близость к Си.... ... Возможно, но чем дальше он отошел бы от Си, тем меньше были бы его шансы на успех. Здесь трудно соблюсти правильную меру, и я думаю, что он очень хорошо справился со своей задачей. (приношу извинения за столь длинную цитату) А некоторые люди вообще высказываются о программировании на С++ довольно кратко, но значительно резче. Здесь весьма обстоятельная критика. Так что, изучайте все получше и делайте выводы сами для себя.

Ответ 3



ИМХО, основное достоинство С - возможность написания быстрых программ. А если не быстрых, то совместимых/работающих с быстрыми. С++ - это С с немного более человеческим лицом. Но основная идея - по-прежнему скорость. Допустим, в std::list вы не найдёте метода sort. Хотя, конечно, есть дополна простых, но неэффективных методов типа std::find или insert в vector... Ну что поделаешь, какую-то цену за удобство надо платить. Это всё я к тому, что я считаю возможность смешивания С++ и С стилей одним из главных достоинств языка. Ну лень тебе сегодня - завёл vector. А завтра оказалось, что это всё тормозит - заменил vector на vector, память выделил один раз на все строки, раздал и всё! Я даже память для массивов частенько выделяю через std::string m_memory; ... m_memory.resize(data_size); return m_memory.c_str() Как ни странно, ни разу сильно не огребал из-за подобных шалостей. Гораздо тяжелей было научиться работать со строками без access violation'ов в С, когда только начинал :) Upd: @VladD, ну естественно не на стеке! Имеется в виду член класса, который живёт дольше, чем используется память, которую он держит. Я потому и написал m_: class C { private: std::string m_memory; ... char *GetWorkMemory(int data_zize) { m_memory.resize(data_size); return m_memory.c_str(); } ...

воскресенье, 10 марта 2019 г.

Python. Стиль программирования

Вопрос очень начального уровня, но интересно мнение со стороны, и возможно советы.
В данный момент я учусь создавать GUI вручную. Появилась одна проблема: после Java привык все называть переменные в CamelCase стиле и давать очень подробные имена (издержка неумения).
К примеру, есть ссылочка на виджет, который представляет собой панель для управлением stack layout (в нем лежат так называемые рабочие модули), и он делает один из рабочих модулей "активным".
Ранее называлось все это безобразие у меня activeWorkingModuleControlPanel. Тут я почитал PEP8 и внес коррективы, но не уверен, правильно ли, и улучшил ли я что-то:
#WM - working modules ... panel_control_wm
тип виджета_что делает_над чем делает
Хочу разобраться в стилях наименования. Если есть какие-то статьи, в которых были бы разобраны различные варианты, с ПОДРОБНЫМ практическим применением в сложных случаях (когда имя ссылочки должно быть информативным в связи со сложностью системы)?


Ответ

Если вы пишете код и в чем-то не уверены, что следуете стандарту - поставьте пакет pep8 - http://pypi.python.org/pypi/pep8. В нем есть скрипт, который указывает на несоответствия стандарту.

среда, 14 ноября 2018 г.

Где объявлять вспомогательные функции?

К примеру, у меня есть класс, который делает WMI запросы, там часто надо преобразовывать QString к BSTR, поэтому я хочу написать функции преобразования. Где мне их лучше объявлять, в этом же классе, если да, то private или public? Создать namespace с двумя функциями только для этого класса? Создать общий namespace для всех функций преобразования, и, пока что, записать туда только две эти функции? Объявить их глобально в хедере этого класса?


Ответ

Как пишет Скотт Мейерс в своей книге «Эффективное использование C++»:
Предпочитайте функциям-членам функции, не являющиеся ни членами, ни друзьями класса. Это повышает степень инкапсуляции и расширяемость, а также гибкость упаковки функциональности.
Если хотите ознакомиться с этим правилом детальнее - см. стр. 105 вышеупомянутой книги.
Если Ваши функции выполняют преобразование и не требуют доступа к закрытам данным-членам или методам Вашего класса - пользуйтесь этим советом, поскольку, если свободная функция способна обеспечить ту же функциональность, что и метод класса, то предпочтительней является свободная функция, поскольку она увеличивает степень инкапсуляции данных. А это уже одна из особенностей, ожидаемых от ООП программ.
Идея использовать namespace, в который Вы поместите свой класс и эти функции преобразования, хорошая, явно лучше, чем подвесить их в глобальной области видимости.

четверг, 25 октября 2018 г.

CSS height в % не работает?

Почему, когда в height пишешь в px всё нормально, а когда в процентах, как на рисунке, ничего не работает? height в процентах нельзя делать?
School.ua


Ответ

Если вы берете проценты, их нужно брать от чего то Т.е. либо пропишите, как сказано выше body, html{height:100%} либо укажите в родительском элементе тоже самое body.style_body { height:100%}

пятница, 5 октября 2018 г.

Где найти хороший код? [закрыт]

Хочу научиться читать чужой код. многие советуют начинать с хорошего кода. во первых это легче, во вторых можно почерпнуть для себя много нового-как писать хороший код. я столкнулся с такой проблемой-трудно найти хороший код. во первых хороший код теряется в множестве плохих, а во вторых мне-начинающему программисту сложно отличить действительно хороший код от не пойми чего. где можно найти действительно хороший код??


Ответ

Если речь идет только C++, то я бы лично смотрел в сторону гугловских opensource проектов, поскольку такой код однозначно требует таланта: Protocol Buffers Chromium gperftools googletest google-glog Также крайне рекомендую читать код Qt.