Pour les collections, dans un projet normal, nous voyons souvent la convention de codage selon laquelle «les collections renvoient des instances vides sans renvoyer de valeurs nulles». En revanche, de nombreuses personnes ont entendu cet accord pour la première fois. En conséquence, nous voyons souvent des vérifications nulles inutiles. De plus, quand quelqu'un avec une expérience Java a aidé avec un projet C #, il y avait une personne qui vérifiait le nombre de cas, puis faisait une boucle for. J'ai l'impression que l'opération de collecte n'est pas bien connue quelle que soit la langue.
Considérez le code qui provient de la base de données et renvoie la valeur qui parvient à la console. Il y a quelques problèmes avec ce code.
internal void Main()
{
var items = GetDataFromDB();
//NG1 NULL vérifier avant foreach
if (items != null)
{
foreach (var item in items)
{
Console.WriteLine(item);
}
}
//NG2 NULL contrôle et compte contrôle avant foreach
if (items != null && items.Count > 0)
{
foreach (var item in items)
{
Console.WriteLine(item);
}
}
//Je suppose que NG3 NULL ne viendra pas, mais pour une raison quelconque, vérifiez le nombre de cas
if (items.Count > 0)
{
foreach (var item in items)
{
Console.WriteLine(item);
}
}
//Erreur si la liste NG4 est nulle
if (items == null)
{
Console.WriteLine("Erreur");
}
}
/**Obtenir des données de DB**/
private List<string> GetDataFromDB()
{
//Récupérez les données de la base de données et définissez NULL en cas d'erreur.
//La nouvelle partie est supposée obtenir des données de Dao.
try
{
var list = new List<string>();
list.Add("1");
list.Add("2");
return list;
}
catch (Exception)
{
return null;
}
}
Suppression de l'hypothèse de null et inclusion de l'exception dans la valeur de retour.
internal void Main()
{
var result = GetDataFromDB();
var items = result.Items;
//Pas besoin de contrôle nul ou de contrôle de compte
foreach (var item in items)
{
Console.WriteLine(item);
}
//Si une exception s'est produite, les informations d'exception sont générées.
if (result.Exception !=null)
{
Console.WriteLine(result.Exception.ToString());
}
}
/**Obtenir des données de DB**/
private Result GetDataFromDB()
{
//Récupérez les données de la base de données et définissez NULL en cas d'erreur.
//La nouvelle partie de liste est supposée obtenir des données de Dao.
try
{
var list = new List<string>();
list.Add("1");
list.Add("2");
return new Result(list, null);
}
catch (Exception ex)
{
return new Result(new List<string>(), ex);
}
}
/**Traitement de la classe de résultats, y compris la valeur de retour et le traitement des exceptions**/
private class Result
{
internal List<string> Items { get; private set; }
internal Exception Exception { get; private set; }
internal Result(List<string> items, Exception ex)
{
this.Items = items;
this.Exception = ex;
}
}
En ne rendant pas la collection nulle, nous avons pu éliminer le code redondant. Cependant, il est nécessaire d'envisager une autre méthode pour ceux qui mettent en œuvre "vérifier le nombre de cas avant foreach". Mystérieusement, le nombre de cas peut ou non être vérifié, les critères sont donc inconnus. Je ne pense pas que la règle «vous ne devez pas vérifier le nombre de cases devant pour ou pour chacune» ne sera pas fixée.
De plus, les personnes qui gèrent des exceptions avec null écrivent le même code même s'il ne s'agit pas d'une collection, ce qui est également difficile à gérer. Ce problème de gestion des exceptions n'est pas propre aux collections.
Pour le moment, "ne pas rendre la collection nulle" résoudra le problème dans une certaine mesure, donc veuillez vous entraîner. Cependant, ce n'est pas strictement interdit, et s'il est absolument nécessaire de le rendre nul, vous devez l'expliquer à l'architecte et obtenir la permission.
protected void main() {
List<String> items = getDataFromDB();
//NG1 NULL vérifier avant pour
if (items != null) {
for (String item : items) {
System.out.println(item);
}
}
//NG2 Après vérification de NULL et vérification du nombre de cas, pour
if (items != null && items.size() > 0) {
for (String item : items) {
System.out.println(item);
}
}
//Je suppose que NG3 NULL ne viendra pas, mais pour une raison quelconque, vérifiez le nombre de cas
if (items.size() > 0) {
for (String item : items) {
System.out.println(item);
}
}
//Erreur si la liste NG4 est nulle
if (items == null) {
System.out.println("Erreur");
}
}
private List<String> getDataFromDB() {
//Récupérez les données de la base de données et définissez NULL en cas d'erreur.
//La nouvelle partie est supposée obtenir des données de Dao.
try {
List<String> list = new ArrayList<String>();
list.add("1");
list.add("2");
return list;
} catch (Exception e) {
return null;
}
}
protected void main() {
Result result = getDataFromDB();
List<String> items = result.getItems();
//Pas besoin de contrôle nul ou de contrôle de compte
for (String item : items) {
System.out.println(item);
}
//Si une exception s'est produite, les informations d'exception sont générées.
if (result.getException() != null) {
System.out.println(result.getException().toString());
}
}
/**Obtenir des données de DB**/
private Result getDataFromDB() {
//Récupérez les données de la base de données et définissez NULL en cas d'erreur.
//La nouvelle partie de liste est supposée obtenir des données de Dao.
try {
List<String> list = new ArrayList<String>();
list.add("1");
list.add("2");
return new Result(list, null);
} catch (Exception e) {
return new Result(new ArrayList<String>(), e);
}
}
/**Traitement de la classe de résultats, y compris la valeur de retour et le traitement des exceptions**/
protected class Result {
private List<String> items;
private Exception exception;
protected Result(List<String> items, Exception exception) {
this.items = items;
this.exception = exception;
}
protected List<String> getItems() {
return items;
}
protected Exception getException() {
return exception;
}
}
[Article précédent (déclaration d'affectation redondante)] (http://qiita.com/csharpisthebest/items/f9ebc741e40037553d5b)
Article suivant (vérification facile des null)
Recommended Posts