Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Wei-Yu

por qué le copian eso a c#? me parece una mierda de feature

no sé quienes son los máquinas que están moviendo esas proposals pero tela, lo único que hace es ofuscar el entrypoint

1
sergioRG

Kaledros

Duda rápida de Go: ¿cuál de las dos se considera mejor práctica? (Recordad, hace dos meses no sabía ni hacer un hola mundo, tened paciencia pls)


response, err1 := //Una cosa que devuelve un resultado o un error

if err1 != nil {
  return "Error"
}

result, err2 := //Otra cosa que devuelve resultado o error

if err2 != nil {
  panic("wtf")
}


response, err := //Una cosa que devuelve un resultado o un error

if err != nil {
  return "Error"
}

result, err := //Otra cosa que devuelve resultado o error

if err != nil {
  panic("wtf")
}

Mi pregunta viene por si hay alguna casuística que haga que la reutilización de err pueda conllevar efectos secundarios (valores basura, etc) o si simplemente se le sobreescribiría el valor y a correr.

3 respuestas
Wei-Yu

eso lo busqué cuando estuve haciendo el redis este y en internet la gente se quedaba tan pancha reciclando el err

a mí me parece una cagada como una catedral reciclar la declaración del error, aunque me espero a la verborrea de nuestro experto desu

1 respuesta
Kaledros

#46324 Ya, yo lo preguntaba porque los expertos de Go de mi curro dicen que p'alante sin miedo, pero tengo muchísimas reticencias a la hora de reutilizar variables y reasignarles valores distintos. Que tampoco estoy programando microcontroladores, no me va a petar la pila por una variable inicializada más.

1 respuesta
Dr_Manhattan

estoy muy en contra de la mutabilidad de variables, siempre lo declaro todo como inmutable, si no estás haciendo un hello work en fast api es mucho más fácil ver dónde la has cagado.

Ahora vendrá desu a defender que las variables deben llamrse a, c, d y que es de fperos crear más de dos variables por función

Wei-Yu

#46325 para mí el problema gordo de reutilizar la variable en go es que el compilador no te va a decir nada si se te olvida comprobar el value del error, cuando el propio lenguaje está diseñado con esa idea.

response, err := //Una cosa que devuelve un resultado o un error

if err != nil {
  return "Error"
}

result, err := //Otra cosa que devuelve resultado o error
anotherResult, err := //Otra cosa que devuelve resultado o error

if err != nil {
  panic("wtf")
}

esto creo recordar que funcionaba perfectamente y, a menos que haya un flag del compiler/linter que no haya visto, no te dice nada... así que es fácil que refactorizando muevas alguna línea de sitio o te comas algún error que se te olvide volver a poner

en el curro me daría mucho por culo que la gente haga algo así ahora que en casa que piense otro que vaya pereza ponerle nombre a todo lol

r2d2rigo

#46323 la mejor práctica es no usar go

3 1 respuesta
pineda

#46323 error es una interfaz, por lo que es un puntero. Puedes reutilizarlo, y el gc eliminará el struct (que normalmente sería nulo) de la misma forma que lo haría si tuvieras 2 variables. La diferencia es que al definir 2 variables error podrías tener 2 variables en el stack (si el compilador no lo cambia) y 1 en el heap, y al definir solo una tendrás 1 en el stack y 1 en heap.
Reutilizarlo no es mala practica

1 2 respuestas
Soltrac

#46328 durísimas declaraciones

#46329 Profe desu va a venir enfadado por lo de que interfaz = puntero, aviso.

2 respuestas
Kaledros

#46329 Ves, esto es lo que necesitaba. Muchas gracias :)

pineda

#46330 y con razon xd he patinado

B

#46330 solo con escribir la palabra puntero ya le ha empezado a salir espuma por la boca y no sabe de qué, verás cuando entre al foro

Seal67

desu es de los que llaman a las variables a,c,d???? :skull: Yo creía que esos eran demonios en vida

1 respuesta
desu

bueno es un fat pointer, creo que todos te hemos entendido, no veo problema en tu mensaje.

#46334 bueno si es una variable local que vas a dropear rapido, o el nombre para una local de una clausura no hay mucho problema y es bastante habitual.

1 1 respuesta
Soltrac

Muy de vez en cuando parece hasta buena persona.

Seal67

#46335 ah bueno, yo es que he visto a gente usar a,b,c,d,e,f,g,h,i,j,k,l,m,n en funciones de 5000 líneas y cuando veo abcd ya me asusto

isvidal

peor es escribir el codigo en catalan

1 respuesta
didinahui

#46323 en Go no hay excepciones ?¿ , se ve sucio ese if ahi dicho por un javero

2 respuestas
desu
#46339didinahui:

excepciones

#46339didinahui:

dicho por un javero

no lo dudes, no tienes ni puta idea de programar

1 respuesta
didinahui

#46340 quien eres tu ?

te acabas de sacar la carrera y te crees guay?

1 1 respuesta
didinahui

yo dandole a Assembly 6502

1 respuesta
desu

#46341 no soy nadie relevante.

tansolo el hecho de preguntar por excepciones como gestion y propagacion de errores hacen ver que eres un fpero que no tiene ni idea de programacion ni ha hecho nada relevante en su vida, precisamente por ello me rio de que digas que eres "javero". no hace falta que lo jures.

ve con dios.

1 respuesta
Soltrac

#46339 No

#46342 ¿Cuántas instrucciones puede tener eso? 10? XD

1 respuesta
pantocreitor

#46338 a mi en un proyecto que me metieron para asesorar me pidieron que el código, los comentarios, los mensajes de los merge request, etc… se los pusiese en catalán y les comenté que se lo iba a poner en inglés porque catalán no se y me dijeron que OK. A la semana me metieron en una daily por sorpresa y empezaron a echarme la bronca en catalán. Me salí del tirón mientras pataleaban, puse verde al PM por la falta de educación ante mi jefe y me piré del proyecto.

Pillé un rebote gordo la verdad.

1
Dr_Manhattan

pues qué quieres que te diga, catalanes catalaneando.

Muchas veces estoy con catalanes en una reu, empiezan en español, al cabo del rato deriva en catalán, cuando me preguntan, les digo que no me he enterado de nada y au

1
desu

Romper con el lenguaje. Romper con el diccionario. Romper con la gramática. Romper con las ideas.

Romper con lo establecido. Rompre con las experiencias. Romper con las expectativas. Romper con el contexto.

Romper con las clases. Romper con las jerarquías. Romper con las imposiciones. Romper con las decisiones.

Romper con los rituales. Romper con las creencias. Romper con el espacio. Romper con el tiempo.

B

Menos romper la camisa de fuerza, estoy seguro de que podrás romper con todo, ánimo.

1
didinahui

#46344 unas cuantas , instruccion set de asm 6502

https://www.masswerk.at/6502/6502_instruction_set.html

1 respuesta
r2d2rigo

#46349 que andas haciendo para la NES

1 respuesta

Usuarios habituales