Feda /dev/

B

#3120 golang trae de serie un formateador de código y al menos en las últimas versiones por defecto te pone tabs, de ahí la gráfica.

https://blog.golang.org/go-fmt-your-code

1
Nitamo

Estoy haciendo la estructura de una API en Lumen y no acabo de decidirme en la manera en la que manejar el convenio para lanzar las respuestas, todas llaman a una libreria propia que formatea la respuesta, lo que no sé es si ponerle capa obligatoria por encima o no.

En principio me había hecho una interfaz para obligar a la implementación de una función que la maneje, pero en algunos casos me parece innecesario.

Por ejemplificar, en algunos casos tendré esto:

private function _handledResponse(){
        $response = [
            'student_id' => $this->student->id
        ];
        ...
        return $this->APIResponse($response);
 }

también puedo querer recibir la respuesta por parámentro...

private function _handledResponse($response){
        ...
        return $this->APIResponse($response);
 }

y en otros casos directamente esto

return $this->APIResponse($response);

Sois pro-interfaces o en casos como este os parecen una chorrada?

Qué pone en el OODH al respecto?

1 respuesta
B

#3122 Lo de usar tab para indexar código puede tener un pase, pero usar "_" en nombres de funciones es de la época de PHP 4 y debería estar tipificado como delito.

http://www.php-fig.org/psr/psr-2/

Dicho esto, si cada clase implementa de una forma distinta el método hay que usar interfaces.

4 3 respuestas
Nitamo

#3123 Se habrá formateado así al copy pastear, pero uso el PhpStorm con TAB -> 4 spaces.

Las barras bajas las utilizo ahora que estoy con la arquitectura para poder identificar las distintas funciones con las que estoy trabajando a golpe de vista, ni siquiera lo utilizo exclusivamente para identificar a las funciones privadas que es para lo que estaba pensado en un principio, es una anotación personal..

Anyway, gracias por el feedback m8.

Los que seguís el PSR-2, tragáis con la apertura de los braces en la línea siguiente de la declaración? I just cant.

2 respuestas
Merkury

#3123 Totalmente de acuerdo

#3124 El PSR-2 es un conjunto de recomendaciones, no es totalmente obligatorio, asi que fuck con lo de linea nueva para los braces.

2 1 respuesta
gohrum

#3123

Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.

lolnope

2 2 respuestas
Nitamo

Lo cierto es que no he conocido a ningún programador español que trague con ese apartado del PSR-2, será algo cultural? xD

Paso encuenta for the loles https://strawpoll.de/dadsc5s

2 respuestas
B

#3126 Por eso se llaman "PHP Standards Recommendations", pero la que comenté tiene todo el sentido del mundo.
#3127 Ahora crea otra que se llame "En las estructuras de control con una sola línea abres llave o no?"

1 respuesta
Nitamo

#3128 El tema está en que en las estructuras de control usar o no llave sí que tiene impacto en la conducta de la ejecución, y salvo casos concretos, me parece muy peligroso.

if ($this->hasEnoughMoney()) 
    $this->giveMoney();
    //Añadida después por otra persona
    $this->updateBalance();

Es un ejemplo de mierda pero se entiende, creo que en este caso no es cuestión de opinión y considero un error no usarlos.

Todo lo que encaja en una línea seguramente se pueda hacer con un ternario.

2 1 respuesta
RaCe

#3129 +1 en esos casos siempre se abre llave por si en un futuro viene alguien a añadir algo detrás

Fyn4r

Las recomendaciones se toman en serio en función de si te tiran un parche abajo o no xd
Manda un parche al kernel de Linux y diles que "es por si alguien viene después", la bronca que te cae.. xd

Saphyel

#3127 en donde trabajo se siguen los PSR como si fuera una biblia mas o menos...

B

Torvalds Went On A Rant And You Won't Believe What Happens Next

3
gbpepe

#3124 #3125 #3126

Yo suelo hacer caso de todas las recomendations, pero la de la llave en la línea de abajo me mata. (En proyectos propios la ignoro, pero ahora estoy con un proyecto para un cliente, en laravel, y el TOC no me deja programar tranquilo xD

PS: Me planteo hacer un pequeño script que se ejecute antes del commit y me baje a la línea de abajo las llaves de apertura xD

1 respuesta
txandy

#3134 en phpstorm por ejemplo tienes el autoformat, le pones que estándar quieres seguir y le das a formatear proyecto y te lo pone "to wapens".

1 respuesta
gbpepe

#3135 Sí, si el problema no es ponerlo (Con sublime lo hago), el problema es mi TOC que no me deja vivir viendo las llaves debajo :cry: :cry:

CsNarsil

4
Kaiserlau

con ruby esas cosas no pasan

2
Nitamo
Se confirma, en España se trabaja así(){

}
Dry-Prime

3
E

https://gist.github.com/elraro/020b220d21761051b05f1044d4fea690

public static String privateKey = "pruebapruebapruebapruebaprueba12";
  public static String server = "http://www.citram.es:8080/WSMultimodalInformation/MultimodalInformation.svc?wsdl";
  static final String serverV2_viejo = "http://sbit1.crtm.es:50080/spai-crtm/srv/prepago/venta/";
  static final String serverV2pre = "http://www.citram.es:50081/VENTAPREPAGOTITULO/VentaPrepagoTitulo.svc?wsdl";
  public static final String server_dev = "http://www.citram.es:8080/WSMultimodalInformation_DEV/MultimodalInformation.svc?wsdl";
  public static final String server_pre = "http://www.citram.es:8080/WSMultimodalInformation_TEST/MultimodalInformation.svc?wsdl";
public static final String server_pro = "http://www.citram.es:8080/WSMultimodalInformation/MultimodalInformation.svc?wsdl";

No tengo nada más que añadir, señoría...

2 respuestas
bornex

Hacer APIs con lumen debería estar prohibido.

2 respuestas
NoRelaX

Ay, los web services...

Saphyel

Para los amantes de js:

2
gbpepe

#3142 Y eso? Mira que tengo que empezar una en breve y por cambiar de SLIM quería probar Lumen xD

1 respuesta
Nitamo

#3142 Hacer APIs con un framework pensando para hacer APIs debería estar prohibido?

1 respuesta
bornex

#3145 #3146 Mi experiencia con Lumen es bastante mala, ya que heredé un proyecto hecho con Laravel y decidimos sacar la lógica a una API con Lumen.

Respuestas de 800ms en local e incluso de 1,5s. El query builder acabé por no usarlo, 14s para enviar correos (encolando), hmmm no se, las respuestas más rápidas que me da la API son de 300ms y son polladas de selects en tablas muy pequeñas. Le han capado mil cosas de Laravel y te quedas ¿por qué?.

No es tan micro como lo pintan. Es un puto Laravel, más lento que el caballo del malo, que se llama Lumen.

Hace poco por poneros un ejemplo, cuando hacíamos una consulta a la base de datos sobre una hora con el

DB::Raw

, el PDO de Lumen (el mismo que el de Laravel), nos metía por la puta cara 4 horas de más. Buscando en el framework y en un issue de github nos dimos cuenta que lo que hace Laravel (y Lumen) por defecto es coger la hora UTC si no le indicas en el .env lo contrario.

Son tonterías que te hacen perder el tiempo.

Elegiría SLIM, o incluso PHP 7 plano.

3 respuestas
Merkury

#3147 Es que el PDO de Laravel/Lumen es una basura XD

Se ponen a hacerlo peor y no les sale XD

gbpepe

#3147 Ufff vale, me quedo con SLIM xd

Quería tirar de Lumen, por si al cliente le da por hacer cambios (que los hará), ampliar a laravel, pero paso, haré lo que necesiten en SLIM y listo (Lo malo es que todos los proyectos de SLIM que he tocado hasta ahora son con la versión 2, y creo que en la 3 cambiaban bastantes cosas... :/)

1 respuesta
bornex

#3149 Sí xD, en la versión 3 cambian un huevo de cosas, pero así es la vida broh. A nosotros de Laravel 5.2 a 5.3 nos han jodido la librería de OAuth2 que usábamos. Ya estamos deprecados.

1 respuesta
Tema cerrado