Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Даже за комментарии на "родных языках" я иногда готов убить 22.12.08 21:10 Число просмотров: 2506
Автор: amirul <Serge> Статус: The Elderman
|
Не говоря уж об идентификаторах.
|
<miscellaneous>
|
Русские имена переменных, за или против ? 22.12.08 17:50 [Den]
Автор: PS <PS> Статус: Elderman
|
Посмотрев на VS2008 обнаружил возможность использовать в коде кириллицу. Переменным теперь можно давать имена на русском языке.
Сижу и думаю, какие в этом плюсы, и какие минусы.
Плюсы ясны: код станет более читабельным, особенно в группе разработчиков, где один говорит на английском как на родном, а другой знает не более двухсот слов.
Минусы: код будет компилиться только под VS2008. Однако это не проблема. Проект на C#, причем под .net3.5
Т.е. это даже и не минус.
Второй: индусам на поддержку этот код не отдашь.
Или отдашь? Нехай русский учат.
Вот я и задумался, а есть ли не религиозные причины не использовать русские слова в коде?
|
|
Крайне против. А если проект выйдет за рамки "родного" или... 24.12.08 12:22
Автор: 3pt Статус: Незарегистрированный пользователь
|
Крайне против. А если проект выйдет за рамки "родного" или будут попытки
портировать или использовать исходники в другом проекте...
Лично я даже против комментариев на "родном".
Технический англ. нормальный программист просто обязан знать.
+ Англ. язык более лаконичен (если мат не использовать ;) + это как стандарт
+ Обязательно где-нибудь у кого-нибудь вылезут грабли
+ Представь ситуацию наоборот - те присылают переменные и комменты на китайском.
Дело даже не в привычке. Взять тот-же 1С. Там русский ещё хоть как-то оправдан.
|
| |
Да, проблема поддержки кода иностранными специалистами есть. 25.12.08 03:15
Автор: PS <PS> Статус: Elderman
|
> Крайне против. А если проект выйдет за рамки "родного" или > будут попытки > портировать или использовать исходники в другом проекте... > Лично я даже против комментариев на "родном". > Технический англ. нормальный программист просто обязан > знать.
И по моему, это единственная не религиозная проблема.
Однако, в скольких проектах вы участвовали, которые отдавались на доработку или сопровождение иностранцам? На моей памяти, такой проект был один!
А сколько проектов отдано на сопровождение отечественным студентам? С десяток наберется!
> > + Англ. язык более лаконичен (если мат не использовать ;) +
Это минус, а не плюс :) Хотя, кому как, конечно.
> это как стандарт
Когда-то стандартно было писать delete после каждого new. Теперь такого слова нет ;))
> + Обязательно где-нибудь у кого-нибудь вылезут грабли
Эти вылезут всегда :)
> + Представь ситуацию наоборот - те присылают переменные и > комменты на китайском.
Вот тут как раз можно дифференцировать проекты типа boost, которые являются международными, и проекты типа CrackBugtraqSite ;)
Есть еще один плюс в локализированых идентификаторах. Его источник - рефлекшн.
Когда отечественному пользователю дают софтину, в настройках которой он может указать имя класса-стратегии, этот класс лучше назвать на русском. (*)
> Дело даже не в привычке. Взять тот-же 1С. Там русский ещё > хоть как-то оправдан.
Вот это как раз еще один плюс. Оправдан почему? Потому что программисты на 1C должны быть квалифицированы в прикладных задачах, и ни ногой не сдалось бухгалтеру, работающему с российским законодательством учить английский.
А чем, собственно, проект по расчету зарплаты на 1C отличается от аналогичного проекта на C# ? Если у того же бухгалтера будет на руках набор действий, типа: Взять_из_базы_данных_последние_записи_в_количестве(), Найти_максимальный_элемент_в_последовательности() и т.п. А все эти действия, не более чем методы в коде, которые сам пользователь уже может компоновать в законченные алгоритмы. Это как раз по поводу (*).
|
| | |
Фтопку таких студентов-девелоперов! 25.12.08 11:47
Автор: Den <Денис Т.> Статус: The Elderman
|
> > Крайне против. А если проект выйдет за рамки "родного" > или > > будут попытки > > портировать или использовать исходники в другом > проекте... > > Лично я даже против комментариев на "родном". > > Технический англ. нормальный программист просто обязан > > знать. > > И по моему, это единственная не религиозная проблема. > Однако, в скольких проектах вы участвовали, которые > отдавались на доработку или сопровождение иностранцам? На > моей памяти, такой проект был один! > А сколько проектов отдано на сопровождение отечественным > студентам? С десяток наберется!
Фтопку таких студентов-девелоперов!
Подобные оп~здолы без знания англ., ничего хорошего написать не смогут.
> Есть еще один плюс в локализированых идентификаторах. Его > источник - рефлекшн. > Когда отечественному пользователю дают софтину, в > настройках которой он может указать имя класса-стратегии, > этот класс лучше назвать на русском. (*)
Это больше походит на недоработку девелопера, который не догадался создать таблицу сопоставления своих модулей с userfrendly именами и реализовать выбор модулей по именам в интерфейсе.
> > > > Дело даже не в привычке. Взять тот-же 1С. Там русский > ещё > > хоть как-то оправдан.
Чем? Нормальному девелоперу не влом выучить несколько слов из бухгалтерского англ./ам. "сленга".
> Вот это как раз еще один плюс. Оправдан почему? Потому что > программисты на 1C должны быть квалифицированы в прикладных > задачах, и ни ногой не сдалось бухгалтеру, работающему с > российским законодательством учить английский.
При чем здесь бухгалтер? Он(а) не лезут в конфигурацию и не дописывают процедуры - это делает разработчик.
Не надо путать локализацию интерфейса пользователя с локализацией исходного кода!
> А чем, собственно, проект по расчету зарплаты на 1C > отличается от аналогичного проекта на C# ? Если у того же > бухгалтера будет на руках набор действий, типа: > Взять_из_базы_данных_последние_записи_в_количестве(), > Найти_максимальный_элемент_в_последовательности() и т.п. А > все эти действия, не более чем методы в коде, которые сам > пользователь уже может компоновать в законченные алгоритмы. > Это как раз по поводу (*).
Такой стиль написания софта, ИМХО - моветон. Вся реализация должна быть полностью скрыта от пользователя за дружественным интерфейсом. И по этому поводу (*) я уже высказался выше.
Недоработка разработчика...
Теперь представь ситуацию, что программа удалась, тебе нужно продавать ее движок за границу, но на поддержку забугорных пользователей у тебя элементарно не хватает ресурсов. Что тогда? Переписывать весь код под языки разных стран?
|
| | | |
Во первых знание английского и умение программировать - не... 25.12.08 13:42
Автор: PS <PS> Статус: Elderman
|
> Фтопку таких студентов-девелоперов! > Подобные оп~здолы без знания англ., ничего хорошего > написать не смогут.
Во первых знание английского и умение программировать - не коррелируют. Во вторых, часто бывает дешевле отдать проект нескольким студентам, чем вести его матерыми разработчиками.
Так что на счет топки ты погорячился :)
> Это больше походит на недоработку девелопера, который не > догадался создать таблицу сопоставления своих модулей с > userfrendly именами и реализовать выбор модулей по именам в > интерфейсе.
Это просто другой стиль, и к этому тоже надо привыкнуть. Посмотри на WPF - все имена классов, все имена команд, все имена событий пишутся в xaml, и используются "на прямую" движком, без всяких таблиц преобразований. У тебя вместо самописных таблиц выступает рефлекшн.
> Чем? Нормальному девелоперу не влом выучить несколько слов > из бухгалтерского англ./ам. "сленга".
Девелоперу невлом, влом бухгалтеру :)
> При чем здесь бухгалтер? Он(а) не лезут в конфигурацию и не > дописывают процедуры - это делает разработчик. > Не надо путать локализацию интерфейса пользователя с > локализацией исходного кода!
Никто и не путает. Когда код был типа strlen( myLovelyString ) != 0 программирование было уделом спецов заточенных под программирование. Основной минус такого подхода - разрыв между пониманием прикладной области и умением программировать.
Теперь, когда появилась возможность писать код типа:
Для_Всех_Сотрудников_В_Департаменте( департамент_программных_разработок )
Посчитать_Премию_За_Месяц( январь );
Программирование отдается в руки специалистов прикладной области, которые совсем не обязаны знать ничего кроме своей работы (в том числе и английский).
> Такой стиль написания софта, ИМХО - моветон. Вся реализация > должна быть полностью скрыта от пользователя за > дружественным интерфейсом.
Очень важное слово "ИМХО" ;)
> Теперь представь ситуацию, что программа удалась, тебе > нужно продавать ее движок за границу, но на поддержку > забугорных пользователей у тебя элементарно не хватает > ресурсов. Что тогда? Переписывать весь код под языки разных > стран?
Поддержка иностранными разработчиками - единственная не религиозная проблема. И об этом я сказал еще в топике, и повторил в нескольких ответах.
|
| | | | |
Еще как коррелируется. Полный MSDN, TechNet, KnowledgeBase... 25.12.08 17:16
Автор: Den <Денис Т.> Статус: The Elderman
|
> Во первых знание английского и умение программировать - не > коррелируют. Во вторых, часто бывает дешевле отдать проект > нескольким студентам, чем вести его матерыми > разработчиками.
Еще как коррелируется. Полный MSDN, TechNet, KnowledgeBase только на английском.
> Так что на счет топки ты погорячился :)
Может быть... Но вряд ли. :)
> Это просто другой стиль, и к этому тоже надо привыкнуть. > Посмотри на WPF - все имена классов, все имена команд, все > имена событий пишутся в xaml, и используются "на прямую" > движком, без всяких таблиц преобразований. У тебя вместо > самописных таблиц выступает рефлекшн.
Данный аспект реализации уж точно не коррелируется со знанием Английского.
> > > Чем? Нормальному девелоперу не влом выучить несколько > слов > > из бухгалтерского англ./ам. "сленга". > > Девелоперу невлом, влом бухгалтеру :)
Правильно! Ибо нефиг бухгалтеру лезть в конфигуратор и средства разработки.
> > При чем здесь бухгалтер? Он(а) не лезут в конфигурацию > и не > > дописывают процедуры - это делает разработчик. > > Не надо путать локализацию интерфейса пользователя с > > локализацией исходного кода! > > Никто и не путает. Когда код был типа strlen( > myLovelyString ) != 0 программирование было уделом спецов > заточенных под программирование. Основной минус такого > подхода - разрыв между пониманием прикладной области и > умением программировать. > Теперь, когда появилась возможность писать код типа: > Для_Всех_Сотрудников_В_Департаменте( > департамент_программных_разработок ) > Посчитать_Премию_За_Месяц( январь ); > Программирование отдается в руки специалистов прикладной > области, которые совсем не обязаны знать ничего кроме своей > работы (в том числе и английский).
Разве раньше прикладной софт писали системные программисты?
Еще со времен DOS "прикладные" вызовы функций ОС были более просты и понятны, нежели вызовы функций BIOS.
> > Такой стиль написания софта, ИМХО - моветон. Вся > реализация > > должна быть полностью скрыта от пользователя за > > дружественным интерфейсом. > > Очень важное слово "ИМХО" ;)
Дык ты спрашиваешь "ИМХО" форумян, они тебе свое "ИМХО и выкладывают. Тут не о чем спорить... Каждый разработчик волен выбирать удобный ему стиль, язык и нотацию, если, конечно, руководство не навязывает иное.
> Поддержка иностранными разработчиками - единственная не > религиозная проблема. И об этом я сказал еще в топике, и > повторил в нескольких ответах.
Разве это не достаточный повод использовать "классический" стиль? ;)
|
| | |
Выучить пару сотен слов на английском куда проще, чем... 25.12.08 10:13
Автор: Heller <Heller> Статус: Elderman
|
> Вот это как раз еще один плюс. Оправдан почему? Потому что > программисты на 1C должны быть квалифицированы в прикладных > задачах, и ни ногой не сдалось бухгалтеру, работающему с > российским законодательством учить английский. > А чем, собственно, проект по расчету зарплаты на 1C > отличается от аналогичного проекта на C# ? Если у того же > бухгалтера будет на руках набор действий, типа: > Взять_из_базы_данных_последние_записи_в_количестве(), > Найти_максимальный_элемент_в_последовательности() и т.п. А > все эти действия, не более чем методы в коде, которые сам > пользователь уже может компоновать в законченные алгоритмы. > Это как раз по поводу (*). Выучить пару сотен слов на английском куда проще, чем изучить программирование на 1С или C#. Не надо лениться. К тому же знания английского точно в жизни не помешают.
> Когда-то стандартно было писать delete после каждого new. > Теперь такого слова нет ;)) А я до сих пор его регулярно набираю. Я что-то делаю не так? :-0
|
| | | |
Взгляни на "умные указатели". std::auto_ptr,... 26.12.08 01:03
Автор: amirul <Serge> Статус: The Elderman
|
> > Когда-то стандартно было писать delete после каждого > new. > > Теперь такого слова нет ;)) > А я до сих пор его регулярно набираю. Я что-то делаю не > так? :-0
Взгляни на "умные указатели". std::auto_ptr, std::tr1::shared_ptr, std::tr1::inrusive_ptr - сила.
|
| | | | |
tr1 пока не использую по причине того, что сидим на 2005-ой... 26.12.08 10:19
Автор: Heller <Heller> Статус: Elderman
|
> > > Когда-то стандартно было писать delete после > каждого > > new. > > > Теперь такого слова нет ;)) > > А я до сих пор его регулярно набираю. Я что-то делаю > не > > так? :-0 > > Взгляни на "умные указатели". std::auto_ptr, > std::tr1::shared_ptr, std::tr1::inrusive_ptr - сила. tr1 пока не использую по причине того, что сидим на 2005-ой Студии, а auto_ptr не подходят по причине необходимости поддержки множества указателей на один объект.
|
|
Украинская юникодная i (не говоря уж о B-В и проч) должны добавить проблем 22.12.08 21:51
Автор: Ustin <Ustin> Статус: Elderman
|
Ещё если сохранить этот текст в utf8, а потом открыть в CP1251, мы выловим кучу вопросов.
А ещё - читая код, голова (как правило) настраивается на восприятие латиницы, и лично меня очень напрягает нажимать альт+шыфт в голове, например, при чтении 1Сных исходников
|
| |
Как-то довелост пропрограммировать на языке с полностью... 23.12.08 10:31
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> восприятие латиницы, и лично меня очень напрягает нажимать > альт+шыфт в голове, например, при чтении 1Сных исходников
Как-то довелост пропрограммировать на языке с полностью русифицированном синтаксисом.
Поначалу заплевал монитор, а недели через три привык так, что не ощущал разницы.
|
| | |
Ну да, это религия, не более того. Тока нарушать её всё равно плохо ИМХО 23.12.08 12:00
Автор: Ustin <Ustin> Статус: Elderman
|
|
|
Даже за комментарии на "родных языках" я иногда готов убить 22.12.08 21:10
Автор: amirul <Serge> Статус: The Elderman
|
Не говоря уж об идентификаторах.
|
| |
Англоговорящих? :)) 24.12.08 18:21
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
Сомниваюсь насчет читабельности 22.12.08 18:13
Автор: Heller <Heller> Статус: Elderman
|
> Посмотрев на VS2008 обнаружил возможность использовать в > коде кириллицу. Переменным теперь можно давать имена на > русском языке. Ужос.
> Плюсы ясны: код станет более читабельным, особенно в группе > разработчиков, где один говорит на английском как на > родном, а другой знает не более двухсот слов. Разработчик, не знающий английского, не имеет права на существование. Как он будет доки читать? Он хочет, чтобы ему весь MSDN перевели?
Более того, я и насчет читаемости сомневаюсь. Подозреваю, что намешивание разных языков в коде будет выглядеть уродливо (как уродливо выглядят сайты, движок которых локализует меню, а все материалы остаются на английском). Учти так же, что в русском имеется множество склонений, и отдельно стоящие слова будут выглядеть слишком кособоко.
> Минусы: код будет компилиться только под VS2008. Однако это > не проблема. Проект на C#, причем под .net3.5 > Т.е. это даже и не минус. > Второй: индусам на поддержку этот код не отдашь. > Или отдашь? Нехай русский учат. Охренеть. Значит, индус пусть учит русский, а у нас уже и разработчики в английском 200 слов знают? Здорово. Вообще последний вопрос абсурден, имхо.
|
| |
Может это всего лишь привычка? 22.12.08 18:39
Автор: PS <PS> Статус: Elderman
|
> Разработчик, не знающий английского, не имеет права на > существование. Как он будет доки читать? Он хочет, чтобы > ему весь MSDN перевели?
Это не более чем мнение. Помню у некоторых преподавателей в институте было мнение, что разработчик не знающий ассемблера не имеет право на существование ;)
> Более того, я и насчет читаемости сомневаюсь. Подозреваю, > что намешивание разных языков в коде будет выглядеть > уродливо (как уродливо выглядят сайты, движок которых > локализует меню, а все материалы остаются на английском). > Учти так же, что в русском имеется множество склонений, и > отдельно стоящие слова будут выглядеть слишком кособоко.
#include "stdafx.h"
#include <sstream>
#include <iostream>
using namespace std;
void OutStringMethodForTest()
{
string stringForOutput = "Hello message";
cout << stringForOutput << endl;
}
void Тестовый_Метод_Для_Вывода_Строки()
{
string строка_Для_Вывода = "Тестовое сообщение";
cout << строка_Для_Вывода << endl;
}
int _tmain(int argc, _TCHAR* argv[])
{
OutStringMethodForTest();
Тестовый_Метод_Для_Вывода_Строки();
return 0;
}
---
Если отбросить привычку - какая функция выглядит приятней ?
> > Или отдашь? Нехай русский учат. > Охренеть. Значит, индус пусть учит русский, а у нас уже и > разработчики в английском 200 слов знают? Здорово. Вообще > последний вопрос абсурден, имхо.
Это была шутка. Проблема поддержки "локализованного" кода действительно возникает.
|
| | |
ИМХО, strOutputTestMethod() как-то привычнее и читабельнее, потому что короче, в т.ч. 24.12.08 18:26
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
раскладки переключать замучаетесь 22.12.08 18:04
Автор: dl <Dmitry Leonov>
|
Стандартные имена, классы, функции ведь никто не отменял.
Ну и неизвестно, как к такому отнесется всякий вспомогательный сторонний софт.
|
| |
пунто свичер нам поможет ;) 22.12.08 18:43
Автор: PS <PS> Статус: Elderman
|
> Стандартные имена, классы, функции ведь никто не отменял. > Ну и неизвестно, как к такому отнесется всякий > вспомогательный сторонний софт.
в сабже шутка (это я теперь для танкистов комментировать буду).
На счет стороннего софта - принято. +1 реальный минус. Хотя опять же, надо посмотреть что за софт, может и не будет проблем.
|
|
|