Por el lado bueno, ahora tengo una nueva serie de frases para mantenerme cuerdo mientras hago revisiones de código… 108.162.249.162 05:47, 17 de abril de 2015 (UTC)

Creo que lo de los emojis se refería a swift donde puedes usar emojis como variables. 108.162.250.168 (talk) 05:53, 17 de abril de 2015 (por favor, firma tus comentarios con ~~~~)

¿Podríamos conseguir un enlace para el lenguaje de Apple? 108.162.249.162 06:09, 17 de abril de 2015 (UTC)

Esto va en nuestro OneNote en el trabajo. Me ha alegrado totalmente el día Jdluk (talk) 08:06, 17 de abril de 2015 (UTC)

Otra razón por la que me alegro de no ser ya un codificador (volvió al diseño de hardware. . . con NINGUNA guía de estilo ;^) 173.245.56.182 (talk) (por favor, firma tus comentarios con ~~~~)

La descripción se lee como si camelCase fuera parte de todos los estilos. Hay estilos que contienen camelCase, pero no todos lo hacen. Además, los diferentes estilos contienen diferentes reglas, por lo que seguir una guía de estilo específica entrará en conflicto con otras, por lo que no es necesariamente una buena idea: a menos que programes en un equipo que haya acordado qué estilo usar, puede ser mejor que no te preocupes demasiado por seguir el estilo exactamente. Por otra parte, si los símiles de Ponytail son precisos, Cueball es probable que descubra un montón de reglas básicas que harán que el programa sea más fácil de leer, incluso para él.

Por ejemplo, hay un montón de estilos para la sangría solo, pero la mayoría de la legibilidad proviene de la idea básica de sangrar el código de acuerdo con el bloque al que pertenece. — Hkmaly (talk) 12:02, 17 de abril de 2015 (UTC)

Por curiosidad he probado a usar 😭 como nombre de variable en Common Lisp. Funciona en SBCL, pero falla en CLISP. 108.162.221.112 12:19, 17 de abril de 2015 (UTC)

Realmente me gustaría saber algo de codificación para poder contribuir, pero mi clase de HTML de 8º grado no me ayudó mucho. El Goyim habla (talk) 12:50, 17 de abril de 2015 (UTC)

La persona cruel podría señalar que HTML ni siquiera es ‘codificación’. (Es marcado, en su mayor parte, a menos que estés incursionando en DHTML o en algunas de las últimas bastardizaciones que se han colado en HTML5). Pero, por supuesto, conocerás la parte en la que se dice «Espera, ¿por qué ese elemento de la tabla está en la línea incorrecta, fuera del final de la línea, o incluso fuera de la tabla?» y cómo facilita el uso de un esquema de nueva línea y sangría en los lugares apropiados (y una política lógica de las líneas que no se deben dividir) para que los errores, como los COLSPANs no contabilizados y el mal emparejamiento de las etiquetas, se puedan rastrear fácilmente. Lo mismo ocurre con el código. Compararlo con la ofuscación del formato HTML (incluyendo el uso de etiquetas id y name sin sentido, aunque consistentes en sí mismas, para que el CSS se cuelgue de ellas) puede emplearse deliberadamente (para evitar una fácil legibilidad/reformación humana) o incidentalmente (porque es creado por un script generador del lado del servidor/CMS al que no se le ha dicho que intente añadir espacios en blanco útiles). Más aún cuando se trata de inserciones de <script> (a menudo deliberadamente ofuscadas a variables de una sola letra, mínimo espacio en blanco y sin saltos de línea, tal vez en un intento equivocado de promulgar la «seguridad a través de la oscuridad», pero por supuesto que entonces es código. Podría decirse que sí. Uno de los objetivos podría ser reducir el tamaño del «código» (incluso cuando se trata de Markup), lo cual es loable teniendo en cuenta la cantidad de cosas sobrecargadas que se pueden obtener (no sé si el «Guardar como HTML»/lo que sea de Microsoft Word es actualmente tan malo como lo era en los primeros días, pero incluso una página web con sólo «Hola Mundo» estaba repleta de información de formato que nunca se molestó en preguntar si era necesaria), pero a menos que no necesites absolutamente (¡o no quieras!) que la gente lea el código, tanto las personas como los scripts de autogeneración deberían intentar impartir elegancia visual. ¡IMO! 141.101.98.192 16:52, 17 de abril de 2015 (UTC)

¿El segundo párrafo de la explicación, que comienza «Una técnica común», añade algo para explicar el cómic? Yo no lo veo, pero es que yo soy de la época del COBOL. Miamiclay (talk) 19:54, 18 de abril de 2015 (UTC)

Yo propondría una reescritura a algo parecido a «Un patrón común en los programadores autodidactas…». En cuanto a la necesidad del párrafo, considero que ayuda a explicar de dónde vienen algunos programadores con mal (o total ausencia de) normas empleadas. Es el tipo de programadores que están acostumbrados a copiar y pegar ejemplos de código y editarlos hasta que haga lo que ellos quieren, introduciendo sin saberlo un horrible nivel de disparidad en el código, además de despreciar cualquier estándar de codificación y patrón de diseño sensato. Puedo hablar por experiencia de que ese comportamiento existe, pero que la mayoría de esas personas abandonan la programación rápidamente o aprenden a adaptar los estándares adecuados con el tiempo. Me alegra decir que estoy en este último grupo. – Erim Secla 141.101.79.67 08:02, 19 de abril de 2015 (UTC)

¿Cómo sabemos que Agile y SaaS son relevantes para esto? 173.245.50.84 17:38, 19 de abril de 2015 (UTC)

No tiene ninguna relación, y además quien haya añadido software-as-a-service probablemente piense que significa algo más de lo que significa Spongebog (talk) 19:30, 19 de abril de 2015 (UTC)Incluso puede haber sido spam o un enlace de autopromoción. Spongebog (talk) 19:32, 19 de abril de 2015 (UTC) Emoji

En mi opinión, la discusión sobre los emoji está un poco fuera de lugar. Los emoji son específicamente las representaciones gráficas (😢), no los smileys basados en texto (T_T). Y las frases sobre el soporte de idiomas utilizan dobles negativos, lo cual es muy confuso, y probablemente debería mencionar que Javascript no parece permitirlo. (Al menos en mis pruebas). Stevage (talk) 14:17, 20 de abril de 2015 (UTC)

Estoy de acuerdo. Los emoticonos y los emoji son dos cosas diferentes.–17jiangz1 (talk) 14:56, 20 de abril de 2015 (UTC) ¿Podemos distinguir entre emoji gráfico y emoji unicode basado en caracteres? La diferencia es que uno se intercambia en el texto normal a través de alguna forma de código de marcado (del lado del cliente o del lado del servidor, ya sea cuando cree que tiene una cadena explícita de emoticonos/etc. como «:)» o encuentra una declaración codificada como «:lol:») mientras que el otro ya está ahí sin necesidad de bytes de imagen adicionales. Excepto por la descarga de archivos de fuentes, por supuesto. Asumo que el anterior (😢) es el último, aunque es un carácter inrrendible para mí, como la mayoría de los ejemplos dados en esta página, y asumo que necesito alguna fuente nueva instalada para verlo en cualquiera de los navegadores con los que lo he probado. Sin embargo, tengo ☺ y ☻ disponibles. Así que al menos puedo emocionar a la manera de Dwarf Fortress (que, irónicamente, utiliza imágenes de los personajes originales). 141.101.99.69 17:51, 21 de abril de 2015 (UTC)

Ew código no Emoji. Estamos en el siglo XXI, actualízate: https://github.com/emj-lang ¡Los lenguajes naturales ftw! ¡No más esto_es_una_variable_que_contiene_el_número_de_xkcds_que_se_publican! 108.162.210.246 21:18, 5 de junio de 2015 (UTC)

En una nota tangencial, una vez intenté instalar un descompilador en IntelliJ copiando y pegando una carpeta (sin darme cuenta de que era el mismo descompilador con el que ya venía IntelliJ) y ejecutarlo en Minecraft. Nombró todas las variables y funciones ☃. Promethean (talk) 22:28, 17 de junio de 2015 (UTC)

Agregó información sobre la calidad del código 3 141.101.104.215 03:43, 7 de mayo de 2017 (UTC)