¿Cuál es preferible ("." Indica espacios en blanco)?Hendidura de Python en "líneas vacías"
A)
def foo():
x = 1
y = 2
....
if True:
bar()
B)
def foo():
x = 1
y = 2
if True:
bar()
Mi intuición sería B (que es también lo que hace vim para mí), pero veo personas que utilizan A) todo el tiempo. ¿Es solo porque la mayoría de los editores están rotos?
El PEP 8 no parece estar claro en este aspecto, aunque las afirmaciones sobre "líneas en blanco" podrían interpretarse a favor de B. El verificador de estilo PEP 8 (pep8.py) prefiere B y advierte si utiliza UN; sin embargo, ambas variaciones son legales. Mi propia opinión es que, dado que Python interpretará con éxito el código en ambos casos, esto realmente no importa, y tratar de aplicarlo sería mucho trabajo con muy poca ganancia. Supongo que si estás muy a favor de uno u otro, puedes convertir automáticamente el uno al otro. Sin embargo, tratar de arreglar todas esas líneas manualmente sería una gran tarea y realmente no vale la pena el esfuerzo, en mi humilde opinión.
Emacs hace B) para mí, pero realmente no creo que importe. A) significa que puede agregar una línea en la sangría correcta sin ninguna tabulación.
Esa línea vacía pertenece a foo(), por lo que consideraría A como la más natural. Pero supongo que es solo una cuestión de opinión.
Estoy de acuerdo en que es más natural, y no estoy de acuerdo, es una cuestión de opinión. Es un hecho. –
No necesariamente llamaría "roto" al primer ejemplo, porque sé que algunas personas lo odian cuando el cursor "salta hacia atrás" al mover el cursor hacia arriba o hacia abajo en el código. P.ej. Visual Studio (al menos 2008) evita automáticamente que esto ocurra sin utilizar ningún espacio en blanco en esas líneas.
Si utiliza Un, puede copiar pegar su bloque en Python Shell, B recibirá el error sangrado inesperado.
Intenté usar A en idlex y en su lugar obtuve un error de sintaxis no válida. – obesechicken13
La versión B no funciona bien cuando se copia/pega en iPython. – Mitch
@ obesechicken13 Se supone que esos puntos son espacios, simplemente están dibujados para que sepas que están allí. – pydsigner
Mi experiencia en el desarrollo de código abierto es que uno nunca debe dejar espacios en blanco dentro de líneas en blanco. Además, uno nunca debería dejar el espacio en blanco al final.
Es una cuestión de etiqueta de codificación.
+1: Tengo mi espacio interior en blanco de la tira IDE. –
no en un idioma donde la sangría es obligatoria, como python –
@ Lo'oris La sangría es obligatoria para el código, pero no para las líneas en blanco. Por lo tanto, cualquier espacio en una línea en blanco es innecesario. –
TextMate rompe el colapso de bloques si usa B, y prefiero A de todos modos, ya que es más "lógico".
Interesante. Lo probé con EditPadPro, que también usa el nivel de sangría para doblar código, y maneja bien las líneas vacías. –
Adición de sangrado adecuado a las líneas en blanco (estilo Un en la pregunta) mejora enormemente la legibilidad del código con el espacio en blanco la pantalla está activado, ya que hace que sea más fácil para ver si el código después de una línea en blanco es parte de la misma sangría de bloque o no.
Para un lenguaje como Python, donde no hay una declaración de cierre o un corchete cerrado, me sorprende que esto no sea parte de PEP. Se recomienda encarecidamente que se edite Python con espacios en blanco en pantalla, para evitar tanto el espacio en blanco al final como la indentación mixta.
Compare la lectura de los siguientes:
A)
def foo():
....x = 1
....y = 2
....
....if True:
........bar()
B)
def foo():
....x = 1
....y = 2
....if True:
........bar()
En Un, es mucho más claro que las dos últimas líneas son parte de foo. Esto es incluso más útil en niveles de indentación más altos.
vi implícitamente desalienta el comportamiento en A porque las navegaciones {/} ya no funcionan como se esperaba. git explícitamente lo desalienta al resaltarlo en rojo cuando ejecuta git diff. También argumentaría que si una línea contiene espacios, no es una línea en blanco.
Por esa razón, yo prefiero B. No hay nada peor que esperar saltear seis o así que se alinea con el movimiento { y termina en la parte superior de una definición de clase.
Hay buenos argumentos a favor de A - copiar en el shell, B lleva a problemas con algunos editores. A menos que también haya problemas con A, parecería ser un caso de "A ayuda en algunos casos, no duele en ninguno" y, por lo tanto, debería usarse A. – Ted
's/^ ([\ t] +) ([^ \ r \ n] *) (\ r? \ N) \ r? \ N/\ 1 \ 2 \ 3 \ 1 \ 3 /'. Buscar: capture pestañas o espacios al comienzo de una línea, capture los caracteres que no sean de línea nueva, si los hay, capturar nueva línea, buscar nueva línea *. Reemplazar: sangría, contenido de línea, nueva línea, sangría, nueva línea. Advertencia: si la línea de sangría abre un nuevo bloque, la expresión regular no detecta esto y simplemente coloca la siguiente línea en el mismo nivel de sangría. * Ignoo el segundo formato de línea nueva y simplemente uso el formato de línea nueva anterior para promover la coherencia –