¿Hay alguna técnica en la programación que consideres que se usa en exceso (IE se usa de manera más excesiva de lo que debería ser) o se abusa de ella, o se usa un poco para todo, sin ser una muy buena solución para muchos de los problemas que las personas intentan resolver? resolver con eso.

Podrían ser expresiones regulares, algún tipo de patrón de diseño o quizás un algoritmo, o algo completamente diferente. Tal vez piense que las personas abusan de la herencia múltiple, etc.

Comentarios en el código

Solo desearía que los profesores universitarios entiendan que no necesitan enseñar a sus estudiantes a escribir 10 líneas de comentarios diciendo que el siguiente código es un bucle for, iterando de 1 a número de x. ¡Puedo ver eso en el código!

Enséñeles a escribir un código de autodocumentación primero y luego comente adecuadamente sobre lo que no puede autodocumentarse adecuadamente en segundo lugar. El mundo del software sería un lugar mejor.

El patrón de diseño singleton.

Claro, es un patrón útil, pero cada vez que un nuevo programador se entera de este patrón, comienza a tratar de aplicarlo en cada clase que crea.

Lo más malvado para proteger la programación tonta. poner todo en un intento de captura y no hacer nada con la captura

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

Me estremezco cuando veo un intento de captura que no hace nada y está diseñado para manejar la lógica tonta. En general, las capturas de prueba se usan en exceso, sin embargo, en algunos casos son muy útiles.

Confíe en StackOverflow para resolver sus problemas en lugar de resolverlo de la manera difícil.

Los nuevos programadores que encuentran la riqueza del conocimiento sobre SO (con demasiada frecuencia) publican antes de pensar y probar cosas.

En mi día tuvimos que codificar de libros, sin internet, sin SO. Ahora sal de mi césped.

OOP evidentemente. Es muy valioso, pero cuando se usa incorrectamente puede oscurecer el código claro de otra manera con bastante facilidad (me vienen a la mente algunos ejemplos de programación S4 en R) y puede proporcionar una sobrecarga tremenda que es innecesaria y puede costarle mucho en rendimiento.

Otra cosa es que (por ejemplo, Perl) la OOP a menudo se reduce a escribir lo mismo al revés: en result = $object ->function(pars)lugar de result = function(object, pars)esto, a veces tiene sentido, pero cuando se mezcla con la programación de procedimientos, puede hacer que leer el código sea bastante confuso. Y aparte de eso, simplemente introduce más gastos generales donde no mejora el diseño. También se reduce a lo que se dice sobre el patrón singleton: debe usarse, pero no en todo.

Yo mismo uso OOP, pero en mi campo (computación científica) el rendimiento es un gran problema, y ​​a menudo se abusa de OOP allí, ya que todos los estudiantes obtienen Java hoy en día. Es ideal para tratar problemas más grandes, para conceptualizar, etc. Pero si trabaja con, por ejemplo, secuencias de ADN en BioPerl, usar los objetos cada vez y trabajar de manera consistente con captadores y establecedores puede aumentar diez veces el tiempo de cálculo. Cuando su código se ejecuta unos días en lugar de unas pocas horas, esa diferencia realmente importa.

Después de haber pasado varios años en ASP.NET Webforms, tendría que decir inequívocamente:

La interfaz de usuario inteligente

Si bien es completamente posible crear aplicaciones en capas y comprobables en formularios web, Visual Studio hace que sea muy fácil para los desarrolladores hacer clic con un clic en formularios estrechamente vinculados a su fuente de datos, con la lógica de la aplicación en todo el código de la interfaz de usuario.

Steve Sanderson explica este antipatrón mucho mejor que yo en su libro Pro ASP.NET MVC:

Para crear una aplicación de interfaz de usuario inteligente, un desarrollador primero construye una interfaz de usuario, generalmente arrastrando una serie de widgets de interfaz de usuario a un lienzo, y luego completa el código del controlador de eventos para cada posible clic de botón u otro evento de interfaz de usuario. Toda la lógica de la aplicación reside en estos controladores de eventos: lógica para aceptar y validar la entrada del usuario, para realizar el acceso y almacenamiento de datos, y para proporcionar comentarios mediante la actualización de la IU. Toda la aplicación consta de estos controladores de eventos. Esencialmente, esto es lo que tiende a salir por defecto cuando pones a un novato frente a Visual Studio. En este diseño, no hay separación de preocupaciones en absoluto. Todo está fusionado, organizado solo en términos de los diferentes eventos de IU que pueden ocurrir. Cuando la lógica o las reglas comerciales deben aplicarse en más de un controlador, el código generalmente se copia y pega, o ciertos segmentos elegidos al azar se descomponen en clases de utilidad estática. Por tantas razones obvias, este tipo de patrón de diseño a menudo se llama antipatrón.

Veo esto ocasionalmente y generalmente resulta de no comprender completamente las expresiones booleanas.

if (someCondition == true)

Reimplementando la funcionalidad central (o proporcionada de otro modo), ya sea por ignorancia de su existencia o por una necesidad percibida de personalizaciones.

Herencia.

No impongas is-a donde no tiene sentido.

Personalización de software estándar.

Si bien puedo reconocer que esto puede ser útil, me pregunto cuánto dinero se gasta en hacer pequeñas cosas para obtener ganancias cuestionables. Aquí es donde una empresa puede gastar cientos de miles, si no millones de dólares, en licencias para algún software que luego se personaliza porque es tan configurable, editable y flexible que realmente no hace mucho por defecto. Al final, es una aplicación personalizada debido a que todo el nuevo código agregó lo que inicialmente se compró.

Usando el cumplidor como depurador.

Ignorando las advertencias del cumplidor o apagándolas por completo.

Variables globales.

Todos los patrones de diseño.

Son como sal o azúcar. Algunos de ellos en su comida lo hacen genial, muchos de ellos hacen que su comida sea una mierda.

No me malinterpretes. Los patrones de diseño son técnicas maravillosas. Los usé mucho. Pero a veces, encuentro programadores, (algunos de ellos mis ex jefes), que tenían estos "¡tienes que usar un patrón de diseño", incluso si no coincide con el problema!

Un ejemplo es el "Patrón de visitante" que está más dirigido a "Colecciones lineales / secuenciales". Tuve que trabajar con una estructura de datos de árbol, una vez. Para "visitar" cada elemento, codifico un método de patrón no diseñado, y un ex jefe insiste en usar o adaptar el "Patrón de visitante". Luego, busco en la red, para una segunda opinión. Bueno, otros programadores tuvieron la misma situación y la misma solución. Y llámelo el "Patrón de visitante jerárquico / árbol"., Como un NUEVO patrón de diseño

Espero que se agregue como un nuevo patrón a los existentes, en una nueva versión del libro "Patrones de diseño".

Uso de excepciones como control de flujo. Algo similar a esta respuesta , pero diferente.

Tragar excepciones es una mala forma porque introduce errores misteriosos y difíciles de encontrar en el código. Usar excepciones como control de flujo, por otro lado, es malo porque hace que el código sea mucho más ineficiente de lo que podría ser, y es conceptualmente descuidado.

El manejo de excepciones solo debe usarse para manejar escenarios realmente excepcionales (duh), imprevistos, no cosas como un usuario que escribe un carácter alfabético donde se espera un número. Este tipo de abuso de excepción es extremadamente común entre los programadores malos en el mundo de Java.

Voy a ir con inflexibilidad a través del ocultamiento excesivo de datos.

Todos sabemos que la abstracción y el ocultamiento de la implementación son buenos, pero más no siempre es mejor. Exagerado, puede obtener un resultado inflexible que no puede hacer frente a los cambios en los requisitos. Para manejar el cambio, no solo tiene que modificar la clase que necesita manejar ese cambio, sino que también debe crear una forma para que la información que nunca antes necesitó fuera accesible a pesar de las capas de ocultación de datos.

El problema es que, como con todos los problemas de encontrar el equilibrio adecuado para cada contexto, requiere experiencia.

Exponer matrices internas

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

De acuerdo con http://www.oracle.com/technetwork/java/seccodeguide-139067.html

copie objetos mutables antes de regresar, a menos que la intención sea compartir el estado.

Estado mutable y bucles. Casi nunca los necesita, y casi siempre obtiene un mejor código sin ellos.

Por ejemplo, esto se toma directamente de un hilo de StackOverflow:

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

Ambos están haciendo lo mismo. Pero no tengo idea de lo que están haciendo. Afortunadamente, la pregunta realmente explica lo que están haciendo, así que pude reescribirlos de la siguiente manera:

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

No hay bucles ni estado mutable. Bueno, está bien, no hay bucles explícitos ni contadores de bucles.

El código se ha vuelto mucho más corto, mucho más simple, mucho más parecido a una descripción de lo que se supone que debe hacer el código (especialmente en el caso de Ruby dice casi directamente "agrupe las cosas por tipo"), y mucho menos propenso a errores. No hay peligro de que se salga del final de la matriz, los errores de poste de cerca o los errores de uno por uno con los índices de bucle y las condiciones de terminación, porque no hay índices de bucle ni condiciones de terminación.

Burlón. Introduce demasiados requisitos artificiales para un desacoplamiento excesivo en su código, conduce a un código de raviolis de ingeniería excesiva y fuerza el diseño de estilo OO por su garganta cuando un diseño más procesal o funcional podría ser una solución más simple para su problema.

Los programadores de Delphi en todo el mundo han descubierto en los últimos dos años lo malo que es usar matrices de caracteres para almacenar bytes debido a la conversión de Unicode a gran escala

Y, "pronto" aprenderemos lo malo que es almacenar enteros en listas cuando queramos hacer el cambio a 64 bits.

Propiedades. Sé que esto es controvertido, pero creo que las propiedades se usan en exceso en .net.

¿Cuál es la diferencia entre estas dos líneas?

public string Property { get; set; }

public string Field;

Para el desarrollador, la diferencia es: absolutamente nada. El formulario compilado es un poco diferente, por lo que si está escribiendo una biblioteca, y esa biblioteca se actualizará en programas, y no puede volver a compilar los programas en sí (por ejemplo, si está escribiendo una interfaz para complementos que debería funcionar en todas las versiones de su software), entonces no debería usar campos públicos porque no puede reemplazarlos con propiedades. En cualquier otro caso, no hay absolutamente ninguna diferencia entre usar un campo o una propiedad automática sin modificadores.