|
|
| Line 1: |
Line 1: |
| == Padrão de Codificação Básica Em Um Nutshell == | | {{Ebuild |
| | |Summary=An audio library tagger, manager, and player for GTK+ |
| | |CatPkg=media-sound/quodlibet |
| | |Homepage=http://code.google.com/p/quodlibet/ |
| | }} |
| | = An audio library tagger, manager, and player for GTK+ = |
|
| |
|
| * empacotamento de palavra (word wrap) de até 160 caracteres
| | ==Installation== |
| * utilize tabs, não espaços, para endentação
| |
| * utilize um tamanho de tab de 4 caracteres (o tamanho de tab pode ser ajustado, mas isso afeta quando você alcançar o limite de empacotamento mágico de 160 caracteres)
| |
| * comentários em linhas separadas, no mesmo nível de recuo como código (seções podem ser marcadas por comentários 'outdented')
| |
|
| |
|
| == Empacotamento de Palavra (Word Wrap) == | | Quodlibet can be installed with |
| | {{console|body= |
| | ###i## emerge quodlibet |
| | }} |
|
| |
|
| Editores modernos fazem um bom trabalho exibindo linhas de texto muito longas, e exibições modernas tem resolução o suficiente para exibições muito superior do que 80 caracteres por linha, mesmo em resolução 1024x768. Você não deve definitivamente dividir pedaço de código elegante de linha única somente pelo argumento de manter a coisa toda sob 80 caracteres. Isso é especialmente ruim se você pegar, digamos, uma linha de 100 caracteres e dividi-la em ''mais'' do que duas linhas somente pelo argumento de mantê-lo sob 80 caracteres de largura. Mas você precisa ou quer usar múltiplas linhas para manter seu código legível, mais poder para você. Somente não faça isso para manter "com compatibilidade com cartão de 80 colunas Apple IIe" por qualquer rasão. Isso é simplesmente bobagem.
| | ==Configuration== |
|
| |
|
| == Tabulações vs. Espaços ==
| | Please expand |
|
| |
|
| Tabulações e espaços tinham uma luta. Tabulações venciam. Eles são mais fáceis de lidar e permite endentação configurável para aqueles que necessitam disso. Eu não me importo com o que alguns outro grupo ou organização diga que convenção seja. Se você não quiser utilizar tabs por que você quer que todos os seus comentários de final de linha apareçam bonitos belamente, então eu tenho uma solução: não utilize comentários de final de linha (veja a próxima seção) e você ficará bem.
| | ==Usage== |
|
| |
|
| == Comments ==
| | Please expand |
|
| |
|
| Add comments that provide some insight into your code, and that help to provide context. Also, because we use tabs, place comments on their own lines, separate from source code, ideally separated by a blank line above and below unless you are verbosely commenting every line of code. This also encourages longer, more descriptive comments that may span multiple lines. If you span multiple lines, use a consistent right margin of 160 characters. Comments help you understand your code when you come back to it a year later, so you are adding descriptive comments for yourself as much as for others. Include information you would find helpful if you had a sudden case of amnesia. They are especially important for free/open source software that needs to be maintained by various people over the years.
| | ==More info== |
|
| |
|
| == Profanity == | | The man page has more details |
| | {{console|body= |
| | $ ##i## man quodlibet |
| | }} |
|
| |
|
| Do not place any profanity in source code comments or variable names. It just makes you look unprofessional, silly and incompetent.
| | ==Troubleshooting== |
|
| |
|
| | Please expand |
|
| |
|
| [[Category:QA]]
| | {{note|Please note this is a first attempt of expanding the wiki by a new user. Don't shoot the messenger!}} |
| | |
| | {{PageNeedsUpdates}} |
| | |
| | {{EbuildFooter}} |
