Самый простой вариант:
делаешь публичную константу string DateFormat = "yyyyMMdd";
где нужно трансформнуть дату в строку вызываешь yourDate.ToString(DateFormat);
где нужно получить из строки дату var newDate = DateTime.ParseExact(DateFormat);
Вариант с культурами правильнее, но для малых приложений и этот сойдет.
Александр Таратин Большинству начальства почти срать (если не требует денег\времени\усилий от начальства - принимай участие, иногда даже поездки оплачивают или поощряют стипухой). И я говорил про общение с увлеченными людьми. По моему опыту, минимум четверть олимпиадников - крайне интересные люди, увлекающиеся ИТ. Опять-таки, конкретно меня личное общение с этими ребятами сильно порадовало, с некоторыми до сих пор поддерживаем контакты. Полагаю, ТСу такие знакомства будут нелишними.
Вадим Егоров пардон, не уловил детали. В любом случае, удачно там потусить.
Александр Таратин олимпиады дадут реальное общение с увлеченными IT людьми, в том числе ровесниками. Учитывая, что Вадим Егоров начинал с районной (и уровень районной, раз уж 1 задачи хватает на третье место) - это может быть офигенно круто.
Читай Петцольда либо Шилдта. Это простейшие книги.
Наследование, полиморфизмы - забей. LINQ - забей. Делегаты, лямбды, события - забей. Многопоточность - если останется время, глянь parallel.For() и Parallel.ForEach(), но лучше забей.
Циклы (for), условия (if), switch, основные типы (int string double) - это база.
Можешь посмотреть про рекурсию, разницу между классами и структурами.
Глянь коллекции (это массив Array, и список List<>).
Дома обязательно накидай примеры чтения файлов - записи в файл.
Понадобятся методы File.Read...(), File.Write...().
С путями ФС работает класс Path.
Поучись парсить строки. Разбить строку "a,b,c" на три строки "a", "b", "c" - это "abc".Split(",").
Обрезать пробелы: " abc ".Trim().
Попрактикуйся с преобразованиями типов Convert.To...(string arg).
Любой базовый тип конвертится в строку методом ToString();
int i = 3;
string strI = i.ToString();
Строки конкатенируют плюсом
string a = "a"; string b = "b"; string c="c";
string result = "a" + "b" + "c";
Символ переноса строки: "\r\n".
Есть еще StringBuilder, но это если надо быстродействие.
Удачи.
Сергей Протько: Факап проектов - не проблема новичка. Как минимум, не фатальная. Если новичок попал в нормальную команду - там его деструкцию заодно и ограничат, так что факапа не будет.
Насчет SOLID, IoC, ООП, ФП - я обобщал все это. Сильно обобщив - это инструменты борьбы со сложностью. Ментальные инструменты, практики, принципы, термин в нашем случае не важен.
Главное: что язык - необходим для разработки вообще, борьба со сложностью необходима при разработке больших проектов\в большой команде, там без нее почти никак.
Но это лирика. У нас два фундаментальных расхождения.
Первое. Человек должен понимать, что делает и зачем. Даже не обращая внимания на вопрос зачем, стандартное обучение: наблюдение, повторение, осознание, расширение. Посмотрел, о, EF7 появилось. Решил пощупать, поставил по шаблонам и инструкциям со stackoverflow, собрал грабли, почитал код\теорию, осознал принципы проблемы, накатил патч. Для наблюдения и повторения понимание не нужно. Делай, что сказали, и мотай на ус.
Второе. Можно совмещать кодинг и фундаменталку. Можно, но не всегда эффективно. Трата ресурсов на переключение контекста. Да, базовые вещи фундаменталки можно посматривать, но не более. Со временем, с опытом - там по всякому бывает.
Я согласен, хорошему программисту фундаменталка нужна. Но она первое время будет мешать новичку, при изучении на сколько-нибудь серьезном уровне.
Сергей Протько: принципы ООП, паттерны - это только методики. Делай так-то, чтобы получилось (не получилось) то-то. Методики это надо изучать, чтобы ими пользоваться. А если у тебя есть знания языка, фреймворка, и опыт работы - изучать эти методики становятся проще.
Язык без ООП выучить можно. ООП без языка и опыта - крайне сложно.
Кодить без языка нельзя. Кодить без знания ООП - можно.
Поэтому сначала нужно учить язык.
Язык - базовая вещь. Поэтому новичкам нужно учить его.
ООП надо для управления сложностью. Без ООП можно писать малые проекты. С трудом - средние. Большие - никак. Качественный код без ООП не написать. Поэтому если нужно писать качественный код или средние\большие проекты - нужно учить ООП. Но учить после языка.
Под ООП выше понимайте техники, паттерны, принципы, ФП (да простят меня функциональщики) - любые методики для обуздания сложности.
Мысль про "не отучили в детстве" здравая. Люто, бешено плюсую. Разве что, расширяя метафору, учить надо, когда из утробы вылез и разговаривать научился. На языке.
Поэтому сначала Петцольд, Шилдт, хотя бы половину. Потом рефакторинг (Фаулера). ООП (хотя книг по ООП не знаю). Art of Unit Testing. Немного GitHub, push\pull\add\remove. А дальше поочередно фреймворк-Макконнелл-фреймворк-IoC-фреймворк-BDD ну и так далее. К тому времени и без наших советов обойдутся. :)
Сергей Протько: г@#$окода бояться - программистом не быть. Где были старшие товарищи чуваков, почему они выпустили это код? Старшие товарищи виноваты больше. Банальное больше знаний - больше ответственность. Возможно - менеджмент.
Да, работать с легаси и просто воняющим кодом никто не любит, но он есть. И долгое время будет. Потому что практики развиваются, традиции меняются. Потому что есть новички, потому что менеджменту надо прям щас.
В конце концов, работа с легаси - одна из граней профессионализма. Недаром в Art Of Unit Testing есть главы, посвященные устаревшему коду.
Что касается до "дать проект" - тут все зависит от срочности\бюджета\выгоды\доступности других профессионалов. Иногда подходящих людей просто нет.
"даш что-то с чем человек не сталкивался": строго говоря, знание ООП здесь тоже может не помочь. Возможно, знаток GoF напишет свой велосипед вместо использования существующей фичи, о которой знает знаток фреймворка. (В велосипеде будет на баг больше, производительность на 10% ниже).
Новички пусть учат язык\фреймворки, после года-двух работы паттерны, SOLID и прочие GRASP. А те, кто выучил, пусть наставляют новичков на путь истинный.
Оп-па, ограничение на длину комента.
Короче, каждому джедаю свой меч, каждому времени свои правила. Новички пусть учат язык\фреймворки, после года-двух работы паттерны, SOLID и прочие GRASP.
Сергей Протько: Вы исходите из того, что человеку нужно ООП. Но, как показывает практика, если знаешь язык и фреймворки не зная - можешь работать. Если же знаешь ООП, не зная языка и фреймворков... согласитесь, сложно такое представить. Так что языка и фремворков большинству достаточно. Хотя Рихтер для начала тяжеловат, как и, возможно, Троелсен.
Теперь по пунктам
"не сможет разобраться что такое инкапсуляция": вначале обучения человеку знать не нужно, что такое инкапсуляция. Он практически не сталкивается с заданиями, где она нужна. В итоге, знания остаются чисто теоретическими, быстро забываются. Базовых знаний про модификаторы доступа вполне достаточно на первое время.
"люди не понимают в чем разница между инверсией зависимости и внедрением зависимостей": строго говоря, это далеко не преступление. Вполне могу допустить, что человек не особо вдумывался в смысл терминов, однако при необходимости заменял аргумент класса в конструкторе\методе на аргумент интерфейса, или выкидывал поля из класса, передавая данные при необходимости аргументами. Сам так делал. :)
Гуглить - это значит смотреть разные источники. В любом случае, при отсутствии опыта всегда есть возможность, что углубишься в регрессионное тестирование и рефакторинг. Возможно, для понимания ключевых вещей нужен релевантный опыт, который набивается на рефакторинге и "регрессе".
SOLID, TDD, GRASP, GoF - это хорошо, но, повторюсь, новичку важнее язык. Без него до SOLID не дорасти, с ним то не у каждого получается. Как пример, банду четырех в свое время толком не одолел. Вот эта статья дала гораздо больше. Сейчас читаю
Alex TestList.Where(element => element.Var2 == 3).FirstOrDefault();
Вернет null, если подходящего элемента нет.
Кроме того, нужно сделать поле Var2 публичным: public int Var2;
Не забудьте вписать "using Linq; " в начало документа (или "using System.Linq", точно не помню).