A RedundantDeclaration is when the programmer is required to declare information multiple times, or explicitly state something that the compiler (or interpreter) could figure out automatically, in order to access/use a language feature.  The compiler will complain if the definition(s) are missing or inconsistent.

This page ''doesn't'' refer to redundant declarations of algorithms, constants, etc. in violation of OnceAndOnlyOnce.  (That said, it can be argued that the topic of this page still violates OnceAndOnlyOnce).  Instead, this page refers to compiler-enforced redundancies that are added to the language to force the programmer to declare his/her intent.

Examples:

	* Variable declarations, especially in languages with DynamicTyping (or languages where NameImpliesType).  BasicLanguage is an example; ordinary variables may be used without an explicit DIM statement.  Experience has shown that this his highly error-prone, as misspelling a variable name creates a brand-new variable, rather than producing an error; this is difficult to debug.  As a result, many Basic implementations provide an option to force all variables to be declared.

	* The override keyword in CSharpLanguage (and the "redefine" clause in EiffelLanguage).  In C#, if a derived-class function overrides a function in the base class, you are required to place the keyword "override" in the derived-class function definition.  Failure to do so produces an error (warning?); conversely specifying override in a function definition for which there is no definition (abstract or otherwise) in a base class is also an error.  Obviously, the compiler can deduce the information by itself if it wants to (most OO languages don't have an override keyword), but requiring the keyword protects against unexpected changes of behavior when a method is added to or removed from a base class.

	* In a similar fashion, the "abstract" keyword when applied to a class.  Useful for declaring a class abstract even if it doesn't have any abstract methods.  The compiler could determine automatically that a class is abstract if it contains any abstract methods (or inherits any that it doesn't provide implementations for), but many programmers prefer a warning in case they simply overlooked adding concrete methods.

	* FunctionPrototype''''''s in C/C++.  Experience has shown that these are highly beneficial (and not necessarily redundant, given how C/C++ toolchains operate); but there was a lot of wailing and gnashing of teeth when AnsiCee encouraged them (and C++ required them).