#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.
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?
#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.
#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.
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
lolnope
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
#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.
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
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
#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".
#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 
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...
#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.
#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... :/)
#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.
