Facebook Google+


[ Legibilidad ] ¿Cómo estructuras tu código?
#1
[Imagen: 1481229542_tgKfqXm1uPaw8Mv.png]
  
[Imagen: 1481229544_FYPTqu1ThwjZw0z.png]
  
[Imagen: 1481229547_6iJoKHeYa8eROcq.png]
  
[Imagen: 1481229549_Btqe592vlYT5qtr.png]
   
[Imagen: 1481229552_StP04fooJliwdWO.png]
    
Yo suelo utilizar las opciones 1, 3 y 5, para mí la 5 es como más legible queda el código, pero igual no es muy buena práctica tanto salto de línea, aunque al compilador eso le da igual. ¿Qué opináis? 

La opción 2 la descarto porque una cosa es agrupar y otra amontonar... Y la opción 4 tampoco la utilizo, básicamente por no acostumbrarme ya que en otros lenguajes, Go por ejemplo, daría error a la hora de compilar al igual que lo daría no utilizar llaves en los condicionales simples (una sola línea).

Las opciones 1 y 3 son básicamente iguales, se me ha colado Big Grin
[Imagen: 1489128820_fbsnVWR5Pg5WrzX.png]
 
Reply
#2
Veo que el objetivo es convertir un objeto en un arreglo pero si ese objeto tiene referencias a otros objetos, la idea es también convertirlos en arrays.

Mi versión:

Código PHP:
class Arrays
{
    public static function 
objectToArray($o)
    {
        switch (
gettype($o))
        {    
            case 
"array":
            case 
"object":
                return 
array_map('self::objectToArray', (array) $object);            
            case 
"NULL":
                return (array) 
NULL;            
            default:
                return 
$o;
            
    }


Si tienes NULL y no haces casting a "array vacio" no pasará por un foreach() por eso el casting.
 
Reply
#3
Sinceramente no hay mucha diferencia que digamos, no ? si quieres "compactar" código en vez de la (2) yo hubiera obviado las llaves en el if() ya que no son necesarias las llaves de bloque cuando tienes una sola instrucción.
 
Reply
#4
Una variante del 3.
CUÁNDO C Y ASM UNEN SUS FUERZAS
TODA RESISTENCIA ES FÚTIL

[Imagen: 1479845315_VVrfgqsvpY2gQJz.jpg]
 
Reply
#5
(12-08-2016, 05:03 PM)master escribió: Veo que el objetivo es convertir un objeto en un arreglo pero si ese objeto tiene referencias a otros objetos, la idea es también convertirlos en arrays.

Si tienes NULL y no haces casting a "array vacio" no pasará por un foreach() por eso el casting.
  
Bueno, en realidad solo me refería al tipo de estructura, llaves, saltos de línea... Big Grin

Es buena idea lo que comentas, aunque ya puestos a evitar errores habría que tener en cuenta otros tipos de datos, así que igual sería más recomendable retornar el array en el default.
  
Código PHP:
switch (gettype($object)) {    

    case 
"array":
        return 
$object;
    case 
"object":
        return 
array_map('self::objectToArray', (array) $object);                   
    default:
        return (array) 
null;  


  
' escribió:Sinceramente no hay mucha diferencia que digamos, no ? si quieres "compactar" código en vez de la (2) yo hubiera obviado las llaves en el if() ya que no son necesarias las llaves de bloque cuando tienes una sola instrucción.
   
Sería respecto a hacer más legible el código, pero a veces pienso que utilizando la opción 5 me excedo con los saltos de línea, aunque es como mejor lo leo. Si tuviera que elegir otra manera sería la opción 3, que junto a la opción 4 son las formas más comunes que puedes ver en los códigos de otros programadores.
  
Antes también obviaba las llaves cuando no eran necesarias, pero con el tiempo leía el código y se me hacía menos legible, porque no solo lo utilizaba en condicionales sino que también lo hacía con los bucles. Luego empecé con Go y como hacer eso suponía un error a la hora de compilar decidí colocar siempre las llaves para mantener en lo posible una manera de programar.
[Imagen: 1489128820_fbsnVWR5Pg5WrzX.png]
 
Reply
#6
Bueno ahora si entiendo a lo que vamos Tongue y tambien me pasa que a veces digo: por qué no abré usado las llaves {}? sobre todo porque cuando hay que agregarlas a posteriori es mas molesto.

Por otro lado soy del estilo de las llaves del lado para mayor legibilidad:

Código PHP:
class Foo
// acá

    
public __construct()
    {
        for (;;)
        {
        }
    
    }



Pero sobre todo cuando son bloques largos, no tanto en bucles ni en métodos sino para un namespace o clase prefiero que las llaves queden a la izquierda y no a la derecha Smile
 
Reply
#7
A mi me gusta tener saltos de linea, todo junto es poco lo que entiendo.

Referente a las {} soy de poner solo las necesarias, pero si ya las ocupé las dejo, no pasa nada porque cuanto las quito preciso me toca volverlas a utilizar. Soy de comentar:

# end of method (si es muy largo)
# end of class


Este tipo de discusiones son interesantes, me tomé el atrevimiento y edité el título Smile
 
Reply
  


Salto de foro:


Browsing: 1 invitado(s)