Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Константин Л., Вы писали:
_FR>>>Ты о том, в что в "merge tools" нет интеллисенса и никто не подскажет истинный тип? Не в нём дело. Даже без интеллисенс и чтение и написание с var удобнее.
КЛ>>написание — безусловно, чтение — не всегда, особенно когда isence нет
_FR>Ну вот просто поверь: это вопрос исключительно наличия опыта. Посмотри сам: люди с заслуживающим уважения бэкграундом пропагандируют "var"; создатели языка пропагандируют "var"; даже, надеюсь, в следующей версии мостодонта С++ появится "auto". А кто спорит? Какие их аргументы? Все сводятся к тому, что "неудобно читать".
Прости, не поверю. В c# его в основном ввели для линка, в с++ не для читабельности, а для нормального foreach, работы с итераторами и для
template <class T, class U>
auto add(T t, U u)
{
return t + u;
}
без auto ты просто такой код написать не сможешь
_FR>Диагноз один: не пробовали научиться. Не пробовали. Пока человек не начнёт говорить на неизвестном емё языке, никогда не научится. Пока не начнёт сам использовать какое-то знание, не разберётся в нём. Пока не заставит себя на два-три месяца использовать "var" везде, где только позволяет компилятор, не отвыкнет от мысли, что "надо знать тип переменной".
давай без диагнозов. я использую var. но считаю, кто крайности вроде "var низзя" и "var везде" не для меня. кстати, использую var пару месяцев плотно. до этого некоторое время игрался с nemerle.
_FR>Не надо! Базовых знаний стандартной библиотеки и Design Guidelines позволят сделать нужные предположения, где это необходимо. Брось писать, притвыкни смотреть на собственоручно написанный код с "var". Потом учись читать чужой. И всё пройдёт.
что пройдет? необходимость мержить код с var?
_FR>Единственно, что мешает — "кривые", ни о чём не говорящие имена переменных, но и это со временем проходит: учишся находить баланс между краткостью и достаточностью.
не, нужно искать баланс в использовании var и конкретных типов.
Re[14]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Константин Л., Вы писали:
_FR>Ну вот просто поверь: это вопрос исключительно наличия опыта. Посмотри сам: люди с заслуживающим уважения бэкграундом пропагандируют "var"; создатели языка пропагандируют "var"; даже, надеюсь, в следующей версии мостодонта С++ появится "auto". А кто спорит? Какие их аргументы? Все сводятся к тому, что "неудобно читать".
Вы меня улыбнули, честное слово. Я бы не стал тут распинаться, если бы с этим не сталкивался. Помимо шарпа, я кодил и на PHP, и на Perl например, даже на JS немного чтобы вдоволь напользоваться varоподобием. Я не пойму, какую реальную выгоду мы получаем используя var? Даже в той же строчке про ReadLine. Мнение других людей мне интересно, но когда оно позволяет что-то упростить или облегчить жизнь, решить какую-то проблему, тут же я вижу только использование "потому что это есть" и "потому что это модно". Напишите ответ только на этот вопрос и я с Вами соглашусь и здорово начну втыкать везде var и пропагандировтаь его использование.
_FR>Не надо! Базовых знаний стандартной библиотеки и Design Guidelines позволят сделать нужные предположения, где это необходимо.
Есть же application-specific вещи, дизайн на них только наталкивает, подсказывает, но не может указать явно.
--------------------------
less think — do more
Re[11]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
КЛ>Однако все известные мне merge tool'ы никакие хинты тебе показывать не будут
Совершенно верно. И именно поэтому, и version control, и diff/merge, и инструментарий а-ля Сode Collaborator, всё это должно быть прямо в IDE, и по-полной программе интегрированно с IntelliSense (в форме ReSharper'а, разумеется )
*Надеюсь, JetBrains нам скоро помогут. А то от Microsoft такого счастья не дождаться, TFS ихний уже видели, свят-свят-свят...
Re[12]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Константин Л., Вы писали:
КЛ>>Однако все известные мне merge tool'ы никакие хинты тебе показывать не будут
D>Совершенно верно. И именно поэтому, и version control, и diff/merge, и инструментарий а-ля Сode Collaborator, всё это должно быть прямо в IDE, и по-полной программе интегрированно с IntelliSense (в форме ReSharper'а, разумеется )
D>*Надеюсь, JetBrains нам скоро помогут. А то от Microsoft такого счастья не дождаться, TFS ихний уже видели, свят-свят-свят...
во во
Re[11]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Pavel M., Вы писали:
PM>Без знания "чего же там", Вы не сможете с этим работать по назначению
Запросто. Бо дальше я просто нажимаю Ctrl+Space в соответствующем месте и телемаркет
D>>Существенная экономия и на наборе имеет место быть в других случаях, например, при возвращении значений навороченных generic-типов. PM>Ммм, IntelliSense достаточно хорошо справляется с генериками.
Проблема в том, что с ними плохо справляюсь я. Выписывать каждый раз какой-нибудь KeyValuePair<CompositeKey<SpreadString, int, HashBase<double>, CompositeKey<string, long>>, Dictionary<...
*Дальше сами продолжайте, раз у Вас IntelliSense такой хороший...
Алиасы тоже не фонтан, бо в их декларации необходимо указывать полные имена типов, и читаемость сразу на ноль уходит.
PM>И тут-то как раз полезно видеть ,что и куда.
Да не видно тут ничего, в дебрях скобок угловых. Видно же будет, когда на объявленной через var переменной Ctrl+Space нажмёшь.
D>>Ну вот видите. А что тогда придирались-то к человеку ? Раз "ежу понятно" ? PM>Я не придрался, я не имею претензий, просто неприятно, когда шарп напоминает JavaScript.
Странные у Вас какие-то ассоциации. Неужели ветеран PHP'шник ? Если так, то "гы" много раз
var в C# не имеет ничего общего с JavaScript'ом. Строгая типизация как была, так и осталась. Это всего лишь удобное сокращение. Разве что ключевое слово выбрано не очень хорошо. Тут уже предлагали infer, было бы лучше, на мой взгляд...
PM>Для действительно тяжелых случаев предназначена документация.
Которую нормальные люди смотрят опять-таки с помощью IDE.
PM>А визуальный образ позволяет избежать "примерно вполне себе понятно")))
А этого позволяет избежать IntelliSense.
PM>var вместо string и подобные радости сэкономят ровно столько времени, сколько использование StringBuilder в однократном сложении строк прибавит производительности Вашей программе.
Это если Вы всё только на примитивах пишите. Хм... Где-то я это уже слышал...
PM>И Вы не учитываете времени на необходимость распознавания и вспоминаний, когда везде стоит var, var, var, var.... Так можно ресурс мышки истратить за месяц )
Не смешите. Основное время при "воспоминаниях" уходит на восстановление архитектуры и взаимосвязей. И var'ы тут на последнем месте...
D>>Неправда. Любое нетривиальное выражение в качестве аргумента, например, тот же вызов функции, и ничего Вы уже не проследите. D>>*А в то что Вы каждый аргумент каждого вызова функции вычисляете отдельно, и складываете в отдельную же локальную переменную с явно заданным типом, я никогда не поверю PM>Но я знаю, что на входе цепочки методов у меня хотя бы "SematicTreeInternal", а не "var"
А чем Вам это поможет-то ??? Типы аргументов в вызове функции никакой связи с Вашим "входом" не имеют.
PM>Я имел в виду сигнатуру, которую Вы видете перед глазами, когда пишете тело метода.
А она тут чем Вам поможет ???
PM>Да, но, если пользоваться техникой, что методы большие нужно разбивать на небольшие, логически завершенные, то все как раз перед глазами.
Ну здрасьте, приехали. Если небольшие методы, то значит они вызывают кучу других небольших методов. И как Вы всё эту толпу собрались размещать "перед глазами" ???
PM>А мышкой можно подергать, если из поля зрения попал аргумент. Вобще, я работаю на клавиатуре больше, как программист ,
Вы, наверное, всё-таки хотели сказать "как формокодер"
PM>а не геймер какой-нибудь, опэтому каждый раз руку к мышке дергать — вот где отвлекает
А я вот вообще стараюсь поменьше, что клавой, что мышкой... Лучше головой, знаете ли
Когда же всё-таки приходится колбасить, то подход разный в зависимости от задач. И если бы Вы внимательно читали мои постинги, то заметили, что на оные действия я ссылаюсь как "с помощью мышки/shortcut'а".
"Чистая" клавиатура более удобна при построении кода, а мышка+клавиатура — при анализе.
Re[12]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Pavel M., Вы писали:
Почитайте другие посты. Оптимально — использовать не чрезмерно, а в меру. Я не ветеран PHPшник, просто не люблю ограничиваться знаниями в одной области и формокодер в последнюю очередь. И, вобще, надоело спорить, ставьте везде var и будет Вам счастье, потом легко на JS перейдете, если потребуется =)) А я буду var ставить где оно упростит жизнь, а не потому что это "модно"
--------------------------
less think — do more
Re[13]: FileIOPermission, доступ к файлам в каталоге
Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
PM> Допустим, Вам дали код на поддержку чужой или Вы недавно пришли на проект. В море var'ов можно легко утонуть или затереть мышку до дыр
Лично мне код с var читать проще. Поэтому, когда я изучаю чужой код — первое что при этом делаю это напускаю на код решарпер, который в том числе заменяет явную аннотацию на var.
А уж если дело дошло до рефакторинга, то наличие var тем более выгодно, так как снижает количество мест, где нужно править при рефакторинге. Иногда (к сожалению, далеко не всегда) достаточно просто поменять тип в одном-двух местах, и код автоматом становится корректным даже без средств автоматизации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
AVK>>>И что с ними не так?
КЛ>>в низ нет isence
AVK>А я разве где то что то про isence писал?
Имеется в виду,что при merge могут быть проблемы из-за сложной читабельности кода, потому что мышкой не подергать над объявлениями.
--------------------------
less think — do more
Re[12]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel M., Вы писали:
PM>>Почему же?
AVK>Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
Но нам приходится в голове держать ту же информацию, что и компилятор держит в памяти. Что и где было.
PM>> Допустим, Вам дали код на поддержку чужой или Вы недавно пришли на проект. В море var'ов можно легко утонуть или затереть мышку до дыр
AVK>и код автоматом становится корректным даже без средств автоматизации.
А раньше это решали с помощью грамотного проектирования AbstractFabric, Builder, etc =)))
--------------------------
less think — do more
Re[15]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Pavel M., Вы писали:
PM>Имеется в виду,что при merge могут быть проблемы из-за сложной читабельности кода, потому что мышкой не подергать над объявлениями.
Такое ощущение — пишу в пустоту. Читаемость кода с использованием var выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel M., Вы писали:
PM>Но нам приходится в голове держать ту же информацию, что и компилятор держит в памяти.
Зачем? Лично я не пытаюсь дублировать при чтении кода компилятор, да это и невозможно, память у меня не абсолютная. Главное при чтении кода — уловить суть, а не проверить типы, и аннотация типов в этом только мешает.
AVK>>и код автоматом становится корректным даже без средств автоматизации.
PM>А раньше это решали с помощью грамотного проектирования AbstractFabric, Builder, etc =)))
Одно другому не мешает, это во-первых. А во-вторых микродизайн очень сильно зависит от используемого языка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel M., Вы писали:
PM>>Имеется в виду,что при merge могут быть проблемы из-за сложной читабельности кода, потому что мышкой не подергать над объявлениями.
AVK>Такое ощущение — пишу в пустоту. Читаемость кода с использованием var выше.
Re[12]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel M., Вы писали:
PM>>Почему же?
AVK>Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
демагогия
PM>> Допустим, Вам дали код на поддержку чужой или Вы недавно пришли на проект. В море var'ов можно легко утонуть или затереть мышку до дыр
AVK>Лично мне код с var читать проще. Поэтому, когда я изучаю чужой код — первое что при этом делаю это напускаю на код решарпер, который в том числе заменяет явную аннотацию на var. AVK>А уж если дело дошло до рефакторинга, то наличие var тем более выгодно, так как снижает количество мест, где нужно править при рефакторинге. Иногда (к сожалению, далеко не всегда) достаточно просто поменять тип в одном-двух местах, и код автоматом становится корректным даже без средств автоматизации.
так читать проще или рефакторить проще?
Re[13]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
AVK>>Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
КЛ>демагогия
Обоснуй.
КЛ>так читать проще или рефакторить проще?
Оба
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
AVK>>>Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
КЛ>>демагогия
AVK>Обоснуй.
1. Вынужденное зло — это что-то из серии личной неприязни.
2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче? Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".
А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей (впрочем, и я, наверное, тоже). У тебя восприятие такое, у меня такое. Мы можем лишь обменяться мнением, а переубедить др др мы не сможем. Поэтому вся наша дискуссия — сплошная демагогия.
КЛ>>так читать проще или рефакторить проще?
AVK>Оба
Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?
Re[15]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
КЛ>>>демагогия AVK>>Обоснуй. КЛ>1. Вынужденное зло — это что-то из серии личной неприязни. КЛ>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче? Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".
Приведи пример кода, в котором из-за замены имени типа переменной на var ты не смог бы разобраться? Или где ухудшилось бы читаемость, на твой взгляд? Я со своей стороны могу привести примеры отсюда — сильно ли улучшится читаемость примеров оттуда, если заменить var на имя типа?
Help will always be given at Hogwarts to those who ask for it.
Re[15]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
КЛ>1. Вынужденное зло — это что-то из серии личной неприязни.
Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.
КЛ>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче?
С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.
КЛ> Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".
Ну давай. Жду твоих примеров.
КЛ>А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей
Это не демагогия. Сама суть любой экспертной оценки — экстраполяция опыта эксперта на экспертируемый предмет. Альтернатива экспертной оценки — только хорошая метрика, но с этим в данной области все очень плохо.
А вот то, что ты, без каких либо обоснований назвал большой кусок текста, содержащий в том числе и логические цепочки демагогией, вот это настоящая демагогия и есть.
КЛ> Мы можем лишь обменяться мнением, а переубедить др др мы не сможем.
А я и не собираюсь переубеждать того, кто переубеждаться не хочет.
КЛ> Поэтому вся наша дискуссия — сплошная демагогия.
С моей стороны никакой демагогии пока нет.
AVK>>Оба
КЛ>Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?
А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>1. Вынужденное зло — это что-то из серии личной неприязни.
AVK>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.
Какие личности? О чем ты? Да и нет у меня неприязни к var. Почитай еще раз, что я к нему "испытываю".
КЛ>>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче?
AVK>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.
Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь. Но только при чем тут он?
КЛ>> Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".
AVK>Ну давай. Жду твоих примеров.
попозже
КЛ>>А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей
AVK>Это не демагогия. Сама суть любой экспертной оценки — экстраполяция опыта эксперта на экспертируемый предмет. Альтернатива экспертной оценки — только хорошая метрика, но с этим в данной области все очень плохо. AVK>А вот то, что ты, без каких либо обоснований назвал большой кусок текста, содержащий в том числе и логические цепочки демагогией, вот это настоящая демагогия и есть.
восприятие кода и экспертная оценка — разные вещи. Вот попытка собсвенное восприятие подогнать под экспертную оценку, да еще и восприятие других людей под нее подогнать — демагогия.
КЛ>> Мы можем лишь обменяться мнением, а переубедить др др мы не сможем.
AVK>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.
аналогично
КЛ>> Поэтому вся наша дискуссия — сплошная демагогия.
AVK>С моей стороны никакой демагогии пока нет.
ну я другого мнения и не ожидал
AVK>>>Оба
КЛ>>Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?
AVK>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?
и тебе можно, и мне можно. дело только в категоричности высказываний.
)
