You can argue by providing examples supporting your case.  Alternatively, you can argue by appealing to more general principles.

For example, in arguing that "exposing public fields is bad," you could say:
By-principle: "It breaks abstraction and encapsulation."
By-example: "This untrusted plugin could set field m_foo to value 4 and cause a null-reference exception on line 16 of file widget.cs".

 

  By example By principle
When it's good Sometimes an example / counter-example can clearly illustrate a problem in an undeniable way. (example) Can rapidly prune the decision tree and avoid wasting time in overly specific discussions that would ultimately lead to a dead-end. 
Abstraction level low - uses specific data points high - uses generalizations
When it's bad This puts a burden on coming up with the "killer example", which you may not be able to do until it's too late. You can waste a lot of time trying to come up with specific examples. The inability to come up with a specific killer example can lead to a false sense of security. (Just because I can't find  a bug in your code does not mean it's bug-free.) Principles may be more subjective and may be more complicated to process.
Principles can be easily misapplied. (eg, "My principle is that our code should never crash; therefore I'm going to explicitly put null checks before every pointer access").
Myers-Briggs of target audience S (sensory) N (intuitive)