How do you manage long lines of code?

I usually tend to split a long line early. I once read a study about UX and form reading on Smashing Mag, and they wrote that one should write input labels aove the input, not beside it, because a human can read faster from top to bottom. I tried it and it's true - for me at least. So I end up with stuff, like

doABarrelRoll()
  .catch(displayErr)
  .then(plane => plane
    .doNotCrash()
    .catch(displayErr)
    .then(() => plane
      .land()
      .catch(displayErr)
      .then(displaySuccess)
    )
  )
;

// or
this
  .document
  .querySelector('.js-foo')
  .innerText
    = this
  .getUsers()
  .map(u => u.name.trim())
  .find(u => u.role === 'admin')
  .email
;

How do you not get confused having thousands of line codes

Simple. I do not have file with thousands of lines of code. I modularize my code and put each module into its own file - sometimes even a single method with all its specific helper functions, if the file gets too long. Then its a simple search on the filesystem for a file with a specific name. Check out my architecture for extremely big modules :)

Your content doesn't exactly match your title -- are you talking long FILES as in number of lines, or long LINES?

I don't tend to write single long lines as I practice the "rule of 76" -- where if a line were to break past 76 characters I use whitespace to break it into pieces. The "enter" and "tab" keys are your friend!

As to long files, that's where bothering to use verbose names comes into play. The search function in your editor is your friend! Use good and meaningful names, if single functions/code blocks are excessively long add comments to your closures so you know WHAT is being closed. Good naming conventions and good commenting can go a LONG ways towards simplifying working with large codebases -- whilst creating things like "function tWwtCent" (that's taken straight from a codebase I cleaned up for a client last week) deserves a good swift kick in the groin. Particularly when what the function does resulted in a meaningful name of "transferWindowToClient" -- reeks of "wah wah, I don't wanna type!" derpitude!

... and you can always break up code into logical sub-files if need be. There are cases where doing so makes sense (when you're pushing up past 50k of code) and cases where it makes no sense.

Also depends on what language you're working in. Often times with things like HTML/CSS or client-side JavaScript if you have enough code for this to be an issue, you're using too much damned code! See the mouth-breathing halfwits who vomit up half a megabyte of CSS to do 48k or less' job, or a megabyte or more of JavaScript on pages that don't even warrant the PRESENCE of scripting... gets even worse when you see 60k or more of HTML doing 16k or less' job. It's SCARY how often I see codebases that are literally wasting five times or more the code needed to do the job.

See the mind-numbingly idiotic halfwitted mentally enfeebled steaming piles of manure that are "front end frameworks" -- which by their very nature make you write as much if not more code, make things harder to maintain, piss on accessibility from orbit, and almost universally finish off by wiping their backside with the very reason HTML even exists in the first place. THEN people have the unmitigated gall to call these dipshit dumbass train wreck laundry lists of how NOT to build a website "easier" EVEN when they've ended up writing five times the code!

Because of course, doing more work than needed is "easier". Sure it is.

Bottom line, if you're REALLY having this be an issue, you're probably doing something wrong... like using more code than you need to, relying on poorly written code from others without knowing how to do it without outside help first, or just plain not having good naming and commenting practices.

Dividing them in functions, or even in different files

Not a complete answer and probably controversial, but you can save quite some horizontal space by fixing to a proprotional font instead of a monospace one.

You can managed code in well formate. and give them proper description.