Execution Plan is different when Constant Variable is Null
You're seeing an example of contradiction detection.  SQL Server's query optimizer is smart enough to perform a few quick checks at the outset of query processing to determine if it can take any shortcuts to return results without doing much (any?!) work.  One such short circuit is to check if the where clause contains an &quot;impossible&quot; limit, such as:
WHERE 1=0

or
WHERE NULL = NULL

SQL Server sees you are comparing something to NULL, which always returns false, and simply returns an empty resultset.  If the items in your WHERE clause were separated with OR instead of AND, then further checks would be performed and you might not see the constant-scan plan.
Comparing any value to NULL using = always returns false.  You may want to use WHERE @c IS NULL instead.  If you rewrite your query using that syntax, you'll see SQL Server does in fact &quot;run&quot; the query.  Consider this:
IF OBJECT_ID(N'tempdb..#t', N'U') IS NOT NULL DROP TABLE #t;
CREATE TABLE #t 
(
    i int NOT NULL
);

DECLARE @c int = 1;

The query plan for this query:
SELECT *
FROM #t t
WHERE t.i = 1
    AND @c = NULL;


Versus the query plan for this query:
SELECT *
FROM #t t
WHERE t.i = 1
    AND @c IS NULL;


The problems around comparing NULL values applies to JOIN conditions as well.  Consider this:
IF OBJECT_ID(N'tempdb..#t', N'U') IS NOT NULL DROP TABLE #t;
CREATE TABLE #t 
(
    i int NULL
);

IF OBJECT_ID(N'tempdb..#s', N'U') IS NOT NULL DROP TABLE #s;
CREATE TABLE #s 
(
    i int NULL
);


I'll insert a row into each table with the value of i set to NULL:
INSERT INTO #t (i) VALUES (NULL);
INSERT INTO #s (i) VALUES (NULL);

Now, if we try to JOIN the two tables in a &quot;simple&quot; query, we get no results returned, since NULL cannot be compared to anything, not even another NULL value!
SELECT *
FROM #t t
    INNER JOIN #s s ON t.i = s.i;


Both tables are scanned by the query processor, as shown in the query plan:

In other words, be careful using NULL values.