Cómo escribir un código con fecha de caducidad?

Marque el código con el atributo System.ObsoleteAttribute, obtendrá una advertencia del compilador, que le molestará para arreglar el código

[Obsolete("You've an ugly hack here")]
public void MyUglyHack()
{
...
}

Alternativamente . . .

Escriba su propio atributo, pasándole una fecha de caducidad en el constructor, en el constructor lanzar una excepción si DateTime.Now >= expirationDate.

La compilación fallará hasta que arregle el código (o más probablemente aumente la fecha de caducidad, o mucho más probable simplemente elimine el Atributo.

Oooohhh - esto es 'orrible. prueba esto para una risita:

[AttributeUsage(AttributeTargets.All)]
public class BugExpiryAttribute : System.Attribute
{
    // don't tell 'anyone' about this hack attribute!!
    public BugExpiryAttribute(string bugAuthor, string expiryDate)
    {
        DateTime convertedDate = DateTime.Parse(expiryDate);
        Debug.Assert(DateTime.Now <= convertedDate, 
            string.Format("{0} promised to remove this by {1}", 
                bugAuthor, convertedDate.ToString("dd-MMM-yyyy")));
    }
}

Luego, decora tu método / clase, etc.:

[BugExpiryAttribute("Jack Skit", "2011-01-01")]
public static void Main(string[] args)
{
...
}

... desagradable: -)

[DESCARGO DE RESPONSABILIDAD] - creado en nombre del interés académico, no el código de producción finese!!

[edit] - solo para aclarar, el código compilado y en producción continuará ejecutándose en/después del 'bugExpriryDate'. solo una vez que el código se ejecuta en el compilador (en/después de la fecha), se mostrará el mensaje de advertencia (depurar.afirmar). sólo pensé que valía la pena hacer esa distinción-salud MartinStettner.

[caveat] - si se utiliza en clases/métodos etc tendría que ser leído a través de reflexión. sin embargo (y esto es interesante) funcionará directamente en el compilador si se usa en sub Main(). ¡qué extraño!! (gracias por el asentimiento Hans...)

Creo que esta es la razón por la que Visual Studio tiene una Lista de tareas. Añadir el comentario:

\\ TODO: Fix this spaghetti by 01APR11

Y se mostrará así

.

Las palabras clave son configurables desde las opciones

Bueno, no hace exactamente lo que está pidiendo, pero podría usar una depuración.Llamada al método Assert () que le alertaría (solo en Debug) de que el código ha caducado. Un beneficio sería que no afectaría inadvertidamente su código de producción (compilación o ejecución), pero sería lo suficientemente molesto en la depuración para que desee corregirlo.

// Alert the developer after 01/07/2011
Debug.Assert(Date.Now < new DateTime(2011, 7, 1))

Una opción más si tiene pruebas unitarias para su código, puede bombardear las pruebas que verifican su corrección. De esta manera no introducirás comprobaciones extrañas en tu código de producción.

También creo que la mejor opción si tienes que poner en hack (probablemente ya has pasado suficiente tiempo mirándolo para arreglarlo correctamente... pero todavía quiere un truco allí) que abrir error / crear tarea / elemento de trabajo (lo que se utiliza para rastrear el trabajo futuro) y decidir si desea solucionarlo más tarde.

Sin controlar el compilador (posible en el marco de tiempo 5.0 con compiler as a service?), usted no va a tener su código caducar. Puede marcar el código como obsoleto, o usar el atributo Obsolete, o similar, para disparar una advertencia, pero la gente puede ignorar las advertencias (muchos desarrolladores que he conocido no han aprendido la regla de que las advertencias son errores).

Creo que es mucho trabajo tratar de proteger a las personas de sí mismas. Es aún más difícil cuando los proteges de sí mismos en el futuro. Marca el código como un kludge y déjalo así.

En lugar de incrustar una bomba de tiempo, tal vez considere aplicar un BUGBUG: comment?

En lugar de forzarte a ti o a otra persona a arreglar un código que puede ser un poco antiestético pero que funciona como se espera en el futuro, puedes hacer una búsqueda en toda la solución y encontrar las partes feas cuando decidas que es hora de bajar y refactorizar las cosas realmente feas.

Rastrea en un bug en su lugar. Luego se puede programar correctamente y priorizar con otro trabajo de refactorización.

TODO los comentarios en el código pueden tener una tendencia a perderse y olvidarse. Lanzar un error de compilador después de una fecha en particular probablemente llevará a que esa fecha sea empujada hacia adelante, o el comentario / atributo eliminado.

Tanto TIME como DATE emiten cadenas y, que yo sepa, no hay forma de analizarlas en la etapa de preprocesamiento.

Hay algunos métodos que puede hacer fácilmente en el código para asegurarse de que el código al menos le avise en tiempo de ejecución. Incluir una afirmación es una forma, poner un comentario de código también funciona, pero la forma en que lo manejo es mediante la inclusión de un comentario doxygen con una nota que explica que la función contiene un hackeo, error o problema de rendimiento que debe ser resuelto. Esto termina siendo filtrado por muchos programadores y es fácilmente visible en el sitio web para que yo u otras personas lo arreglen.