Comments by "xybersurfer" (@xybersurfer) on "" video.

  1. Pablo Carbonell i tend to agree especially when you want to use breakpoints, but it depends on the LINQ expression. i've personally mostly stopped using LINQ-to-SQL because i run into performance issues with the simplest LINQ-to-SQL queries, that are hard to solve when you don't even know how the SQL query will come out (can't follow any advice from database admins because you can hardly change the underlying query). i now typically use a parametric query with SqlCommand and then get the result with SqlDataReader.Cast<IDataRecord>() and if necessary use LINQ-to-Objects on the client-side to turn this flat result into objects without having to do any looping. in my experience it's mostly LINQ-to-SQL queries that get long. i still frequently use LINQ-to-Objects when it makes things short
    2
  2. it's scary how much of of what you mentioned i've run into. here are 2 more: - not using exceptions because you don't understand how they work and instead using if statements (arrow anti-pattern) and passing magic values - creating your own version of existing tools like a database editor or object to perform SQL queries but in an extremely limited way compared to the original tool (the inner-platform effect) and dictating everyone should use that. i've haven't seen this in one of our code bases (i would fix it if it was), but we have had to deal with third party products that operate this way these probably won't pass code review (but sadly not every place has code reviews): - copying and pasting the same code in the same program several times - using globals instead of parameter passing - using database tables when a view would suffice (tables are global variables in disguise) - reverting things or starting down the same path after things like the above has been fixed (not really an anti-pattern but this is the worst to me. not learning)
    1