I would like to get a consensus from more senior level colleagues here on how to handle a situation where you may disagree on a technical problem or code review with a colleague in an environment that has no standards.
I always try to sell ideas from a position of confidence and assertiveness. I do my best to defend my ideas, not shut down if someone disagrees. I would come back and tell them that I considered what they want to do and why I decided on the other approach as well. If I knew a more senior person that agreed with me, I would try to get them to present the idea and utilized that, not to get my way, but to learn how to disagree and resolve disagreements in that organization.
Basically, depends on the situation. If it is something that you are experienced on and if it is your responsibility, and if someone is talking without having a clue, I would possibly suggest to put your reasoning with examples. Be assertive that it is your responsibility but be open to hear the other side and ask questions to understand where your colleague is coming from.
In case you think what your colleague is trying to sell is not any good, list the disadvantages of his/her approach.
A lack of standards seems to be the particular issue here. I am a senior developer (15+ years) and in most of my experience there are usually established patterns in existing code that can be followed when solving new problems.
In the absence of any precedent, if your colleague is of the same experience level as you, then can you not seek the opinion of a more senior staff member? If I disagree with the approach someone with less experience has taken, I try to explain it by exploring some of the issues that can arise with the approach and why other solutions may mitigate them.
That said, in software development there are usually many "right" ways of doing something, just as there are many "wrong" ways. Most modern software teams adopt the Agile methodology and the KISS principle ("Keep It Simple, Stupid") which advocates that if two or more solutions achieve the desired outcome, the optimal choice is the simplest one to implement.
Anecdote: in my earlier years as a developer I struggled with this principle because I wanted to perfectly engineer my code and use lots of design patterns and abstractions, partly to make the solution elegant and also to future-proof my work. Only through experience have I learned that it's as likely any future-proofing is wasted effort due to the ever-changing nature of software systems. Trying to forward-engineer usually makes it harder in the long run, except in that rare case where your early optimization happens to fit the change you didn't know was coming.
First of all, you can support your claims with evidence from people who have studied these sorts of problems longer than either you or your colleague. Read some books from the likes of Bob Martin, Kent Beck, Martin Fowler, and Michael Feathers. Learn how to describe the problems with code in more concrete terms than, "This way feels cleaner."
Second, code talks louder than words. People are often easier to convince when looking at real code, instead of just a theoretical better implementation. Also, sometimes you might be surprised yourself when you think a certain way to write it will be cleaner, so you write it that way and find out there are problems you didn't consider.
Finally, people are more willing to make changes when it's earlier in the process. A code review feels like the last step before calling a change "done," and people are loathe to make significant changes at that point. Try to foster a culture of doing design reviews earlier, before you spend a lot of time coding. Start by asking for whiteboard design reviews of your own code. When other people see how it improved your design, they will start asking for it for their own code.