What Terrible Code Practices Are Killing Your .NET Project?

I am a second‑year graduate student supervising a data‑mining project and have been forcing my junior teammates to read “Design Patterns” and a .NET OOP book, only to discover a litany of poor coding habits in their SVN submissions.

Variables are named with unclear pinyin like JuleiMethod instead of descriptive English names.

One MainWindow class contains about five thousand lines, a hundred fields and dozens of methods, violating the Single Responsibility Principle.

Multiple classes duplicate similar functionality instead of using inheritance or composition.

Frequent unnecessary use of as casts and LINQ filters makes the code noisy.

Constructors with dozens of parameters are used instead of default values or property setters.

Overreliance on the Singleton pattern and static members raises concerns about memory reclamation and extensibility.

When porting Java code to C#, getters and setters are redundantly added despite C#'s property syntax, and excessive Javadoc‑style comments clutter the files.

Comment blocks far exceed the actual code, containing abandoned test code and dead sections.

Improper element removal in collections using foreach leads to runtime errors; a custom LINQ‑based RemoveElements extension is proposed.

Fields are exposed with trivial getters/setters and then overwritten indiscriminately in methods.

Code is copied between projects without creating reusable libraries, resulting in a tangled mess of unrelated files.

Debug output relies on Console.WriteLine even for GUI or service applications, ignoring proper logging frameworks like log4net.

Excessive use of raw arrays instead of .NET collections causes unnecessary allocations; deferred execution via IEnumerable is suggested.

Simple repetitive code is manually duplicated instead of using loops, inflating the codebase.

Event handling in WPF is tightly coupled to UI elements, making future changes painful; adopting data binding and MVVM is recommended.

Large debug files are committed to SVN without proper version control hygiene.

Below is the proposed extension method for safely removing elements from any IList while optionally executing a delegate on each removed item:

public static void RemoveElements(this IList source, Func<object, bool> filter, Action<object> method)
{
    var indexes = (from d in source where filter(d) select source.IndexOf(d)).ToList();
    indexes.Sort();
    for (var i = indexes.Count - 1; i >= 0; i--)
    {
        if (method != null)
        {
            method(source[indexes[i]]);
        }
        source.RemoveAt(indexes[i]);
    }
}

These observations serve as a cautionary tale for anyone mentoring junior developers: enforce clear naming, keep classes focused, avoid unnecessary duplication, use proper design patterns, and adopt professional logging and library practices to ensure code remains maintainable and graduation‑ready.