IMO важно различать #if и #define. Оба могут быть полезны, и оба могут быть чрезмерно использованы. Мой опыт показывает, что #define более вероятно будет использован чрезмерно, чем # if.
Я потратил 10+ лет на программирование на C и C ++. В проектах, над которыми я работал (коммерчески доступное программное обеспечение для DOS / Unix / Macintosh / Windows), мы использовали #if и #define в первую очередь для решения проблем переносимости кода.
Я потратил достаточно времени на работу с C ++ / MFC, чтобы научиться ненавидеть #define при его чрезмерном использовании - что, как я полагаю, имеет место в MFC примерно в 1996 году.
Затем я более 7 лет работал над проектами Java. Я не могу сказать, что пропустил препроцессор (хотя я наверняка пропустил такие вещи, как перечисляемые типы и шаблоны / шаблоны, которых у Java не было в то время).
Я работаю в C # с 2003 года. Мы широко использовали #if и [Conditional ("DEBUG")] для наших отладочных сборок, но #if - это просто более удобный и немного более эффективный способ делать то же самое, что мы делали в Java.
Двигаясь вперед, мы начали готовить наш основной движок для Silverlight. Хотя все, что мы делаем, можно было бы сделать без #if, с #if меньше работать, что означает, что мы можем тратить больше времени на добавление функций, которые запрашивают наши клиенты. Например, у нас есть класс значений, который инкапсулирует системный цвет для хранения в нашем ядре. Ниже приведены первые несколько строк кода. Из-за сходства между System.Drawing.Color и System.Windows.Media.Color, #define вверху дает нам много функциональных возможностей в обычном .NET и в Silverlight без дублирования кода:
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
#if SILVERLIGHT
using SystemColor = System.Windows.Media.Color;
#else
using SystemColor = System.Drawing.Color;
#endif
namespace SpreadsheetGear.Drawing
{
/// <summary>
/// Represents a Color in the SpreadsheetGear API and provides implicit conversion operators to and from System.Drawing.Color and / or System.Windows.Media.Color.
/// </summary>
public struct Color
{
public override string ToString()
{
//return string.Format("Color({0}, {1}, {2})", R, G, B);
return _color.ToString();
}
public override bool Equals(object obj)
{
return (obj is Color && (this == (Color)obj))
|| (obj is SystemColor && (_color == (SystemColor)obj));
}
...
Суть для меня в том, что существует множество языковых функций, которые могут быть использованы чрезмерно, но это не является достаточной причиной, чтобы исключать эти функции или устанавливать строгие правила, запрещающие их использование. Я должен сказать, что переход на C # после программирования на Java так долго помогает мне оценить это, потому что Microsoft (Андерс Хейлсберг) более охотно предоставляет функции, которые могут не понравиться профессору колледжа, но которые делают меня более продуктивным в моей работе и, в конечном итоге, позволит мне создать лучший виджет за ограниченное время, которое есть у любого человека с датой отправки.