Глубокая пустая проверка, там лучший путь?

Считаю ли я это плохим стилем кодирования? Ну да.

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

Есть несколько исключений, где я думаю, что короткие имена переменных в порядке:

Индексы (в основном для циклов), такие как:

for (int i = 0; i < 10; i++)
{
}

Переменные, используемые в очень ограниченной области, такие как запросы Linq, лямбда-выражения или некоторые из примеров, уже упомянутых как Streamwiters и -readers, и это еще один пример, где я думаю, что короткие имена переменных в порядке.

Кроме того, всегда возникает вопрос о том, насколько читаемым в конечном итоге является ваш код. Причина, по которой я бы постоянно нюхал на людей, которые используют короткие переменные имена, заключается в том, что для меня это показатель того, что они, как правило, не заботятся о том, насколько читаем их код (особенно для других).

Хорошо, я не понимаю, как TempFrame (ваш передний план) может быть серым цветом, если вы используете вычитание фона. Вы, должно быть, используете особый алгоритм. Но предполагая, что TempFrame является серым цветом, вы бы сделали следующее:

cv::Mat mask = tempFrame > 0.5;

cv::Mat outFrame;
capturedFrame.copyTo(outFrame, mask);

Это код OpenCV 2.0 выше. Число 0.5 является порогом, вам нужно установить его на что-то подходящее. Если вы не используете изображения с плавающей запятой, вы, вероятно, установите его на 128 или что-то подобное. Это то же самое в коде OpenCV 1.1:

CvMat* mask = cvCreateMat(tempFrame.rows, tempFrame.cols, CV_8UC1);
cvCmpS(tempFrame, 0.5, mask);

CvMat* outFrame = cvCreateMat(capturedFrame.rows, capturedFrames.cols, CV_32FC3);
cvCopy(capturedFrame, outFrame, mask);

Я нашел это расширение весьма полезным для сценариев глубокого вложения.

public static R Coal<T, R>(this T obj, Func<T, R> f)
    where T : class
{
    return obj != null ? f(obj) : default(R);
}

Это идея, которую я получил из нулевого оператора объединения в C # и T-SQL. Хорошо то, что возвращаемый тип всегда является возвращаемым типом внутреннего свойства.

Таким образом вы можете сделать это:

var berries = cake.Coal(x => x.frosting).Coal(x => x.berries);

... или небольшой вариант выше:

var berries = cake.Coal(x => x.frosting, x => x.berries);

Это не лучший синтаксис, который я знаю, но он работает.

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

Итак, я создал метод расширения, который позволит вам написать:

var berries = cake.IfNotNull(c => c.Frosting.Berries);

Это вернет ягоды, если ни одна часть выражения не является нулевой. Если будет встречен NULL, нуль возвращается. Хотя есть несколько предостережений, хотя в текущей версии она будет работать только с простым доступом участника, и он работает только на .NET Framework 4, потому что он использует метод Memberexpression.update, который новый в V4. Это код для метода расширения INTNOTNULL:

using System;
using System.Collections.Generic;
using System.Linq.Expressions;

namespace dr.IfNotNullOperator.PoC
{
    public static class ObjectExtensions
    {
        public static TResult IfNotNull<TArg,TResult>(this TArg arg, Expression<Func<TArg,TResult>> expression)
        {
            if (expression == null)
                throw new ArgumentNullException("expression");

            if (ReferenceEquals(arg, null))
                return default(TResult);

            var stack = new Stack<MemberExpression>();
            var expr = expression.Body as MemberExpression;
            while(expr != null)
            {
                stack.Push(expr);
                expr = expr.Expression as MemberExpression;
            } 

            if (stack.Count == 0 || !(stack.Peek().Expression is ParameterExpression))
                throw new ApplicationException(String.Format("The expression '{0}' contains unsupported constructs.",
                                                             expression));

            object a = arg;
            while(stack.Count > 0)
            {
                expr = stack.Pop();
                var p = expr.Expression as ParameterExpression;
                if (p == null)
                {
                    p = Expression.Parameter(a.GetType(), "x");
                    expr = expr.Update(p);
                }
                var lambda = Expression.Lambda(expr, p);
                Delegate t = lambda.Compile();                
                a = t.DynamicInvoke(a);
                if (ReferenceEquals(a, null))
                    return default(TResult);
            }

            return (TResult)a;            
        }
    }
}

он работает, изучая дерево выражения, представляющую ваше выражение, и оценивая части один за другим; Каждый раз, проверяя, что результат не нулевой.

Я уверен, что это может быть расширено так, чтобы другие выражения, чем Memberexpression поддерживаются. Рассмотрим это как доказательство концептуального кода, и, пожалуйста, имейте в виду, что наказание производительности, используя его (который, вероятно, не имеет значения во многих случаях, но не используйте его в тесной петле :-))

Один из вариантов - использовать Null Object Patten, поэтому вместо null, когда у вас нет торта, у вас есть NullCake, который возвращает NullFosting и т. Д. Извините, я не очень хорошо объясняю это, но другие люди см.

• Пример использования Паттена нулевого объекта
• В wikipedai написано о Паттене нулевого объекта