1. C# / Говнокод #4911

    +121

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    [DataContract]
         public class DismissForm1ReportItem {
              [DataMember]
              public int grPersonalCode { get; set; }
              [DataMember]
              public string grPersonalName { get; set; }
              [DataMember]
              public int grIndustrialCode { get; set; }
              [DataMember]
              public string grIndustrialName { get; set; }
              [DataMember]
              public string cexCode { get; set; }
              [DataMember]
              public string cexName { get; set; }
              [DataMember]
              public int totalDismissed { get; set; }
              [DataMember]
              public int dismissedProfGroup1 { get; set; }
              [DataMember]
              public int dismissedProfGroup2 { get; set; }
              [DataMember]
              public int dismissedProfGroup3 { get; set; }
              [DataMember]
              public int dismissedProfGroup4 { get; set; }
              [DataMember]
              public int dismissedProfGroup5 { get; set; }
              [DataMember]
              public int dismissedProfGroup6 { get; set; }
              [DataMember]
              public int dismissedProfGroup7 { get; set; }
              [DataMember]
              public int dismissedProfGroup8 { get; set; }
              [DataMember]
              public int dismissedProfGroup9 { get; set; }
              [DataMember]
              public int dismissedProfGroup10 { get; set; }
              [DataMember]
              public int dismissedProfGroup11 { get; set; }
              [DataMember]
              public int dismissedProfGroup12 { get; set; }
              [DataMember]
              public int dismissedProfGroup13 { get; set; }
              [DataMember]
              public int dismissedProfGroup14 { get; set; }
              [DataMember]
              public int dismissedProfGroupOther { get; set; }
         }

    Откуда вот берутся такие наклонности? Как можно так называть члены классов? (Это только один подобный класс из множества!) Может быть сделать специальную версию Framework'а для таких людей, где классам давать имена Class1, Class2, ..., а методам Method1, Method2, ...

    Запостил: Guid, 13 Декабря 2010

    Комментарии (27) RSS

    • как я понимаю, в бд такая же каша )))
      Ответить
      • В том-то и дело, что нет =) Видимо, рученки не дотянулись =)
        Ответить
      • Это проблема бд.
        Например люди которые тебя просят сделать шлюз для вывода во внешку(т.е возможно у них уже есть сайт, какая-то большая сеть). И тебе приходится делать такую вещь, чтобы те люди которые буду конектится к твоему WCF серверу знали какое поле что означает из БД.
        Ответить
        • тоесть где-то в базе у кого-то есть поле dismissedProfGroup9?
          да, трудные нынче времена
          и в кащенках интернеты имеются.

          зы: хранить неимеющие смысла для поиска поля в отдельных колонках вообще не нужно
          Ответить
          • Представим так, что есть таблица в бд с выше описанными колонками. Тебе дают задание написать службу WCF которая будет отдавать записи в структурированном ввиде, т.е класс выше. Для чего тебе менять имена полей если клиент который будет в твоей службе цепляться будет привычней работать с полями с которым он уже приспособлен работать и описаниях их знает на зубо????
            Ответить
            • Да я все понимаю)
              Если так, то программист правда не виноват (особенно если он это автоматом сгенерил).
              Просто ему тогда лучше подумать о смене работы
              Ответить
              • Да, но возможно он фрилансер
                Ответить
                • вот потому-то я никогда не буду фрилансером.
                  жизнь фрилансера это миллионы мелких говнопроектиков
                  Ответить
                  • Лучше навалить одну БОЛЬШУЮ кучу ! :)
                    Ответить
                    • в крупном проекте есть хотя бы шанс сделал все по уму
                      у фрилансеров такого шанса нет
                      Ответить
                      • Полностью согласен
                        Ответить
                      • это при условии, что команда состоит не из одного единственного говнокодера.
                        Ответить
                        • это да)
                          но в крупных проектах комманда редко из него состоит
                          Ответить
                  • отвечаю: много маленьких проектиков лучше одного большого говна. чем больше волос на голове, тем охотней колтун заплетается
                    Ответить
                    • народная мудрость, однако
                      Ответить
                    • "много-маленьких-проектиков" это "вот тебе фтп, сегодня до шести вечера сделай, что бы воооот тут выводился ник пользователя"

                      всяким скрамам, континиус интегрейшенам, паттернам и рефакторингам там места нет
                      Ответить
                      • ага, а дали задание в 7
                        Ответить
                      • но вообще маленькими проектиками я называю небольшие каталоги на пыхе, укладывающиеся в месяц разработки-тестирования-доведения до ума.
                        а большие проекты - это монстры гос-венного уровня, в разработке уже 5-10 лет, где каждый модуль как отдельный проект. Там, где не только сложная система прав юзверов, но и даже текст-видео конференции
                        Ответить
          • Чтобы править это положение надо срубать всё накорню, т.е начинать править саму БД. НО что если смена имён полей и структуры в целиком слишком затратно выходит???
            Ответить
        • угу, попросить программиста стоит как минимум в 3,5 раза дешевле чем нанять грамотного DBA
          Ответить
          • странно, я раньше думал что схемами БД занимаются программисты.
            а DBA занимаются перформансом, секурити, бекапами, максимум индексами и репликами БД.

            Теперь оказывается что что бы знать, что dismissedProfGroup9 -- хуевое имя для поля -- надо быть ДБА.

            Скоро про джойны будут только ДБА знать, ага)
            Ответить
            • ДБА возможно удивится, зачем так аттрибуты назвали, но главное то, что ДБА не умеет наколеночные аппликейшн-серверы делать и поэтому сделает локдаун базы, что и требовалось в самом начале
              Ответить
    • Такое бывает, когда независящая от тебя система делает поля такими выше(бд).
      Скорее всего WCF сервер которые отдаёт что-то из системы независящей от тебя, т.е было необходимо приблизить это всё для понятности аудитории которая уже работала с это бд
      Ответить
    • cex?
      Ответить
    • нуббля
      а вы обфусцируйте все фрейймворки и дайте таким удодам.
      пусть у них будут классы из буквы и нумерка, и тоже со всем остальным.

      PS. как-то отвязывал от серийного номера одно такой обфусцированное глюкало на яве. софт был куплен но его защита от взлома так глючила порой что пришлось ее отключать )))
      - пришлось дизасемблировать и грузить подменяя класслоадер :)
      вот там таких пронумерованых тьма была. :))
      Ответить

    Добавить комментарий