Sub GetFriendFile()
        'DESCRIPTION: Opens the corresponding .h / .cpp file
        Dim currentFileName As String
        Dim newFileName As String
        currentFileName = Application.ActiveDocument.FullName
        newFileName = ""
 
        If (UCase(Right(currentFileName, 2)) = ".H") Then
            newFileName = Left(currentFileName, Len(currentFileName) - 2) + ".CPP"
        ElseIf (UCase(Right(currentFileName, 4)) = ".CPP") Then
            newFileName = Left(currentFileName, Len(currentFileName) - 4) + ".H"
        End If
 
        If newFileName <> "" Then Application.Documents.Open(newFileName)
 
    End Sub
 

Для того чтобы его использовать идете в Tools | Macros | Macros IDE появится новое окно в котором будет открыт MyMacros проект. Добавьте новый модуль, назовите его скажем Switch2cpp. И далее вставьте в него функцию GetFriendFile, сохраните и затем назначьте сочетание клавиш.

Для этого выберите Tools|Options|Environment|Keyboard и там выберите из лист бокса Macros.MyMacros.Switch2cpp.GetFriendFile и сочетание клавиш, которые будут выполнять данный макрос, после этого не забудьте нажать кнопку Assign - наслаждайтесь.

function vFrmUnsubscribe(form)
{
    total = form.length;
        
    var errorMsg = new Array("Please enter a valid Email Address.",
                             "","","","","","","");

    for(var i = 0; i < total; i++)
    {    
        if(i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6 || i == 7)
        {
            continue;
        }
        if(i == 0)
        {
            if(form.elements[i].value == "" || form.elements[i].value.length<1)
            {
                alert(errorMsg[i]);
                form.elements[i].focus();
                return false;
            }
            if(!vEmail(form, i))
            {
                form.elements[i].focus();
                return false;
            }
        }    
        if(form.elements[i].value == "" || form.elements[i].value.length < 1 
                                    || form.elements[i].value == -1)
        {
            alert(errorMsg[i]);
            form.elements[i].focus();
            return false;
        }    
        
    }
    return true;

А вот вообще супер  function isDigit(digit)
{
    var charOk = "0123456789";
    return !(charOk.indexOf(digit) == -1)
}

function isAlphaNumeric(digit)
{
    var charOk = 
      "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
    return !(charOk.indexOf(digit) == -1)
}

}

Почему ваш код – отстой

Автор: Дейв Эстелс (Dave Astels)

Ваш код – отстой, если он не работает

Работает ли ваш код? С чего вы это взяли? Можете ли вы это доказать?

Если ваш код не имеет тестов, он – отстой. Я имею в виду – всесторонние, в достаточной мере детализированые программные тесты (известные также как Юнит-тесты (unit tests)), а также более высокоуровневые функциональные (functional) и интеграционные (integration) тесты. Тесты, которые автоматизированы. Тесты, которые запускаются постоянно. Включая программные тесты, запускающиеся после всякого изменения кода.

Без адекватных тестов (подразумевая – как по количеству, так и по качеству), вы просто не можете иметь уверенность в том, что ваш код работает как нужно. Задумайтесь: даже если вы сами уверены в том, что вы сделали... почему кто-то ещё должен слепо верить этому? А что вы скажете о людях, которые будут работать с вашим кодом в будущем и изменять его? Как они будут знать, что ваш код работает после изменений, выполненых позже?

Ваш код – отстой, если он не поддаётся тестированию

Отлично, вы решили добавить тесты в ваш код. Чаще всего, это не так-то просто. Скорее всего, ваш код просто-напросто не был спроектирован и/или реализован так, чтобы его было легко тестировать. Это означает, что вам придётся делать изменения в нём, чтобы сделать его поддающимся тестированию... не разрушив никакой функциональности (собственно это в наше время и называется рефакторингом (refactoring)). Но, выполняя такие изменения, можно ли быстро и уверенно сказать, что вы ничего не сломали в работающем коде, если в нём не было всесторонних и детализированых тестов? Вряд ли. (Похоже на задачку про курицу и яйцо – прим. перев.)

На самом деле, дела обстоят ещё хуже. Если вы принимаете решение о том, что вы будете писать тесты для всего своего кода после того, как написан сам код, вам придётся приложить дополнительное усилие для того, чтобы передизайнить/переписать этот код с тем, чтобы сделать его тестируемым.

Сохранение адекватного уровня тестирования при подходе, когда тесты пишутся после самого кода, требует времени и планирования. И если вам приходится делать дополнительную работу для того, чтобы сделать код тестируемым... хм... этот код – отстой.

Написание тестов прежде написания самого кода означает, что код по определению поддаётся тестированию. Если вы отрабатываете тесты поочерёдно, вы получаете ещё больший выигрыш, поскольку каждый тест требует только инкрементальных изменений в коде, который уже проверенно работает.

Ваш код – отстой, если его трудно прочесть

Код должен быть легко читаем. Стив МакКоннелл (Steve McConnell) сказал в своём выступлении на SD West '04: код должен удобно читаться, а не удобно писаться.

Здесь следует отметить несколько факторов. Выбор хороших, говорящих сами за себя, имён – хорошее начало. Стремитесь к простым решениям, даже если они кажутся более многословными или неэффективными. Является ли эффективность проблемой, станет известно только впоследствии, при профилировании проекта в реальной ситуации использования продукта.

Выбирайте стиль и соглашения о форматировании на ранней стадии проекта, и следуйте этим соглашениям. Требуйте от других следования им же. Это будет легче сделать, если каждый внесёт свою лепту в такое соглашение. Всё это сделает ваш код единообразным и более лёгким в прочтении.

И избавляйтесь от дублирования кода во всех его проявлениях. Более подробно об этом – ниже.

Ваш код – отстой, если он непонятен

Этот пункт весьма близок к предыдущему. Код может быть читабельным, но, тем не менее, труднопонимаемым. Возможно, он читается хорошо, но вводит читающего в заблуждение. Представьте: вы потратили много времени, чтобы выбрать хорошее имя переменной, но способ её использования и её значение изменились в то время, как имя осталось прежним. Это ещё хуже, чем зашифрованное имя... по крайней мере, в последнем случае, читатель знал бы, что имя бессмысленно. Но если же имя не отражает сути, читатель будет иметь беспочвенные суждения о том, что происходит в коде, что в итоге приведёт к непониманию, и в конце концов – к багам.

Ваш код – отстой, если он догматично следует ультрамодным framework ценою соблюдения хороших практик дизайна и имплементации

Например, Боб Мартин (Bob Martin) недавно поднял вопрос о догматическом использовании private полей и getters/setters для простой структуры данных (например, Data Transfer Object – DTO). Если поле прозрачно для чтения/записи, почему бы просто не сделать поле public? В большинстве языков это возможно. Конечно, в некоторых – нельзя. Например, традиционно в Smalltalk все поля (fields) являются private, а все методы – public.

Обычно хорошо, если вы можете выбросить какой-то фрагмент из кода или избежать его написания. Использование тяжёлого framework обычно требует того, чтобы вы писали значительную часть кода, который попросту не имеет никакой ценности с точки зрения бизнеса (business value).

Есть множество разнообразных лёгких frameworks для Java. Они являются ответом на тяжёлые frameworks (такие как EJB), которые в последнее время фактически стали догмой. У O'Reilly есть книга об этом, в соавторстве с Брюсом Тейтом (Bruce Tate).

Когда вы выбираете framework, предпочтите более лёгкий framework, который будет делать всю необходимую работу. Использование средств типа Hibernate, Prevayler, Spring, PicoContainer, NakedObjects, и т. д., может действительно быть выигрышным во многих случаях. Никогда не принимайте слепо тяжёлый framework только потому, что это модно сегодня. Хотя также слепо не следует выбирать и лёгкий framework. Всегда взвешивайте прежде, чем принять решение.

Ваш код – отстой, если в нём есть дублирование

Дублирование – скорее всего, единственная, самая значительная вещь, которую нужно искоренить в вашем коде.

Дублирование имеет несколько форм:

текстовое

Оно – самое простое и легко находимое. Когда у вас есть секции кода, которые идентичны или очень похожи. Чаще всего – это результат программирования методом copy & paste. Есть несколько способов избежать этого вида дублирования, включая: выделение методов (extracting methods) и повторное их использование (reusing), превращение метода в шаблонный метод (template method), вынос его в суперкласс (superclass) и предоставления вариантов в подклассах (subclasses), и другие базовые виды рефакторинга. Подробности см. в книге «Рефакторинг» Мартина Фаулера (Fowler's "Refactoring").

функциональное

Это – особый вид текстового дублирования, когда у вас есть различные функции/методы, которые предназначены для одного и того же. Его можно часто встретить в проектах, которые разделены между группами разработчиков, недостаточно хорошо взаимодействующих друг с другом. Также, оно может быть результатом copy & paste, или просто незнания существующего кода или библиотек. Практики и полиси (practices and policies), которые стимулируют и способствуют знанию всего объёма кода и всех библиотек и frameworks, находящихся в использовании, позволяют избежать функционального дублирования.

временное

Оно – немного более трудное, менее ясное, и не так легко обнаруживаемое. У вас есть временное дублирование, когда одна и та же работа делается повторно – в то время, когда так не должно быть. Это не проблема в том же понимании, как предыдущие две формы дублирования, так как это не приводит к наличию лишнего кода. Но это может стать проблемой при масштабировании системы, когда повторяющаяся работа начинает отнимать много времени. Для решения этой проблемы могут использоваться различные техники кеширования.

Из трёх вышеназванных типов, текстовое дублирование является самым худшим. Оно загрызёт вас раньше других, когда ваша система будет расти. Оно имеет гадкую особенность быть подобной вирусу: когда ваш код заболел дублированием, он уговаривает вас думать: "О, это не такая уж и проблема, если я просто возьму вот этот кусок кода, положу его копию здесь и немного подгоню его. В конце концов, все вокруг делают это!" Это сильно напоминает Разбитое Окно (Broken Window), о котором говорили Дэйв Томас и Энди Хант (Dave Thomas & Andy Hunt). Если вы не возвыситесь над мелочами, которые появляются так или иначе, всё в конце концов пойдёт коту под хвост.

Итог

Итак, весьма вероятно, что какая-то часть вашего кода – отстой.

Что с этим можно сделать? Ну, для начала вам придётся признать факт (и я надеюсь, что эта статья вам помогла в этом) и сознаться в том, что это – проблема.

Затем, у вас есть выбор. Вы можете что-то с этим делать. Вы можете изучить новые способы работать: способы, которые помогут вам писать лучший код. Вот и чудесно. Если хотя бы один программист здесь делает это, я буду счастлив.

Ваш второй вариант – не делать с этим ничего, и продолжать писать код так же, как прежде.

Это ваш выбор. Выбирайте с умом.

Proverbs are used to express universal truths or life lessons in a short and memorable fashion.  I find that they are a great way to keep things in perspective, both in life and in work.  Because of this, I have assembled 10 programming proverbs that every developer needs in their arsenal.

1. There is no smoke without fire

Relax. It's probably just another fire drill

Poorly designed code tends to manifest itself through some common tell-tale signs.  Some examples of these are:

• Giant classes and/or functions
• Large blocks of commented out code
• Duplicated logic
• Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency.  If you don't address the underlying problem it will come back to burn you later on.

Оригинал (Английский): Top 10 Things That Annoy Programmers

Перевод: © tigra-alive, tpumapa3m, VlexZ, Андрей Дягель, the_corrector, n-two, kycok, Александр, dmitry, Dim, kuzyakiev, sergakrem.livejournal.com .

Microsoft Certified Professional Developer (MCPD) - Сертифицированный профессиональный разработчик

The Microsoft Certified Professional Developer: Windows Developer (MCPD: Windows Developer) - эта сертификация подтверждает, что Вы имеете необходимые знания и навыки, которые требуются для построения сложных клиентских приложений на платформе Windows Forms с использованием .NET Framework 2.0.

Кандидаты на статус MCPD: Windows Developer в первую очередь должны выполнить требования для получения сертификации MCTS: .NET Framework 2.0 Windows Applications (два экзамена: 70–536 и 70-526). После этого необходимо сдать еще один обязательный экзамен. В приведенной ниже таблице указаны учебные курсы, необходимые для подготовки к экзаменам на статус MCPD: Windows Developer.

 How to...

Обзор программ сертификации Microsoft