Code to test four conditions if C#
Naming and underscores

Underscores help to separate long sentences. But variable names should not be long sentences. You should drop the underscores, stick with camelCasing (as per convention), and shorten the names.

bool errorsFound;
bool importFailed;


The underscores in your constants are not as much of an issue. I have generally moved away from the SCREAMCASING for constants and instead just PascalCase them (without underscores); but that's not a globally agreed upon standard.

As an aside, unit and integration test methods often do have long sentences for names, and underscores are actually useful there. So you're definitely allowed to use underscores where appropriate. Local variables with long names are hardly ever appropriate.



Simplifying the logic

if ((result.Count == 2) &amp;&amp; (!is_The_Import_Has_Failed_Exist))
{
    result_REJECT = result[1].ToString().Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);
    StatusResult = Properties.Resources.ARGS_RESULT_OK_REJECT;
}      

if ((is_The_Import_Has_Failed_Exist) &amp;&amp; (result.Count == 2))
{
    result_REJECT = result[1].ToString().Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);
    StatusResult = Properties.Resources.ARGS_RESULT_KO_REJECT;
}   


These two evaluations share some commonalities, and their bodies are identical (assuming OK/KO is a typo). This can be merged into a single evaluation:

if(result.Count() == 2 &amp;&amp; (!is_The_Import_Has_Failed_Exist || is_The_Import_Has_Failed_Exist) )
{        
    result_REJECT = result[1].ToString().Split(new string[] { "\r\n" }, StringSplitOptions.RemoveEmptyEntries);
    StatusResult = Properties.Resources.ARGS_RESULT_OK_REJECT;
}




Clear naming

var is_Import_Failed_Exist = ...;
var is_The_Import_Has_Failed_Exist = ...;


For the life of me, I cannot figure out what the difference between them is. The naming of these variables (and the constants after which they are named) is not good, since a reader cant figure out what they represent.

returnObject = new ReturnObject { ... }


ReturnObject is such a vague name that it fails to express anything meaningful. I'll happily admit that I've struggled coming up with names for return DTOs too, but it needs to have some sort of descriptive name, e.g. ImportStatusDto or ImportStatusResult.

Properties.Resources.ARGS_RESULT_OK_REJECT


"OK" and "reject" seemingly contradict one another. Is this a good outcome, or a bad one? It's unclear and needs better naming to make this clear.

else if (is_No_Errors_Found_Exist)
{
    StatusResult = Properties.Resources.ARGS_RESULT_OK;
}
else if (is_Import_Failed_Exist)
{
    StatusResult = Properties.Resources.ARGS_RESULT_OK; // I assume "KO" was a typo
}


As a developer reading your code, it's very confusing why the failure of an import is considered a positive ("OK") outcome. This seemingly contradicts the evaluation above where the existence of errors is clearly not OK.

This may be a bug in your code. In that case, you probably would've spotted the bug easier if your variable names had been easier to read (see the above tips).  

If this isn't a bug, then I'm still inclined to conclude that your naming introduces confusion where none should have existed.

CountLines 


This sounds like a command or instruction ("Hey, you! Count those lines!"), which is how methods should be named.  

Variable names (except for booleans) should be nouns or noun phrases. LineCount is the better name here.

For completeness' sake, boolean names should generally adhere to yes/no questions: isAlive, hasFood, ... or in other cases phrasings that strongly convey a binary result: userWasDeleted, importFailed, ...
In all of these cases, if I were to put a question mark behind the name, it would be bad English but you would understand the question and would easily identify what the meaning of "yes" and "no" is.



Avoid negative variable names

is_No_Errors_Found_Exist


While you can read it now, this can quickly get out of hand. How would you check that errors were found?

if(!is_No_Errors_Found_Exist)


That's a double negative, and really hard to parse. It's much better to stick with "positive" naming and then negate the boolean value

bool errorsFound = ...;

if(!errorsFound) { ... }

if(errorsFound) { ... }


In this example, there's no need to use a double negative, which improves readability.

Your internal voice should read this as "not errors found", which it intuitive and clearly expresses the intention of the evaluation.

Note that when I say "positive", I mean "not negated" instead of "good". A boolean called isFailed is a "positive" naming. Not because failure is good (it clearly isn't), but because it's not negated.
importDidNotFail would be the "negative" naming (because of the "not"), which you should try to avoid to enhance overall readability.



In conclusion

This is more of a review on your question than the code, but there is a common thread here.


  First I have two conditions on the number of list elements,then in one of these conditions I have two others conditons to treat it


Try to read this from the perspective of a StackExchange user who knows nothing about you or your code. Does this explain what your code is trying to achieve?

I think you're explaining things the way they already make sense to you, while not considering how others will (or won't) understand what you write.

I mention this because code readability should be written from the perspective of those who don't know the code. Whenever you name something (a variable, a method, ...) you need to ask yourself a simple question:


  Would a developer who is new to the project understand what this method does/what this variable expresses?


This is by far the biggest issue in your code. Your naming has made it very hard for anyone else to read your code and understand its purpose.  

And it's not just about other people. If you start working on another project, and in a few months' time you have to return to this project, you're going to be scratching your head too, because you won't remember all the things you currently know and will have to build up that working knowledge again.

The other minor issues/bugs I've found are actually fairly common in codebases where readability is hampered, because low readability leads to a high likelyhood of making unintentional mistakes. 

I suspect that if you work on improving your code readability, you'll automatically start seeing how to improve parts of the code more and more.