12 de abril de 2010

Google Python Style Guide

Rodando por aí descobri que tem um google-styleguide, e que ao lado de C++ e Objective C, há o Google Python Style Guide.

De maneira geral esse guia recomenda o que já é recomendado em Python com alguns acréscimos com os quais concordo plenamente, incluindo a convenção sobre nomes:


Naming


module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_VAR_NAME, instance_var_name, function_parameter_name, local_var_name.
link
Names to Avoid
  • single character names except for counters or iterators
  • dashes (-) in any package/module name
  • __double_leading_and_trailing_underscore__ names (reserved by Python)

Naming Convention
  • "Internal" means internal to a module or protected or private within a class.
  • Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
  • Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
  • Use CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it's confusing when the module happens to be named after a class. ("wait -- did I writeimport StringIO or from StringIO import StringIO?")
***

A PEP 8, guia de estilo Python, desencoraja o uso de sublinhados em nomes de módulos, mas contrariando a PEP eu vinha usando "modulo_nome" mesmo assim, e agora vejo que não estou só.

Entretanto, não uso variáveis privadas (que iniciam com duplo sublinhado), somente internas (que começam por um único sublinhado), nunca vi necessidade de variáveis privadas em Python, mas acho que dependendo do grau de polimorfismo ou mágica talvez seja necessário usá-las.

Nenhum comentário: