Hacker News 의견

• 함수 이름과 클래스 이름 같은 기호를 검색하는 것은 코드의 구문을 이해하는 도구를 사용하는 것에 비해 약함

  • "정의로 이동"과 "사용처 찾기" 기능만으로도 텍스트 검색의 필요성을 크게 줄일 수 있음
  • 지난 10년 동안 주로 사용자에게 보이는 문자열만 검색해왔음
  • 이런 게시물은 저자가 자신의 언어에 맞는 더 나은 도구를 배우는 데 시간을 투자해야 한다는 것을 의미함
  • 좋은 IDE만으로도 많은 시간을 절약할 수 있음

• grep 도구에 "슈퍼 대소문자 구분 없음" 모드가 있으면 유용할 것 같음

  • 예를 들어 "FooBar|first_name"을 검색할 때 모든 케이스를 매칭할 수 있도록 확장하는 것
  • 이런 기능이 기본값이 되지 않을 상황을 떠올리기 어려움

• grep 가능성에 대해 지지함

  • 스웨덴어로는 "grep-bar"나 "grep-barhet" 같은 단어가 실제로 존재함
  • "greppbar"는 "이해할 수 있는"을 의미하고, "greppbarhet"는 "이해할 수 있는 가능성"을 의미함

• Hamilton을 설계할 때 함수 정의와 그 하위 사용을 쉽게 grep할 수 있도록 하는 것이 목표였음

  • Python 데이터 변환 세계에서는 grep이 크게 도움이 되지 않는 코드베이스를 만들기 쉬움

• 'greppable'은 자체적으로 사용되지 않는 단어/개념임

  • 오랫동안 이를 조직 원칙으로 사용해왔음
  • 코드 구조화의 가장 좋은 방법 중 하나임

• 조건부 문자열 보간을 사용한 복잡한 예제를 본 적이 있음

  • 프로젝트에 처음 참여했을 때 UI에서 본 세 단어를 찾는 데 너무 오래 걸렸음
  • 나중에 이 코드를 쉽게 grep할 수 있는 문자열로 모두 바꿈

• 많은 코딩 스타일과 도구는 문자열 상수를 줄 길이와 상관없이 한 줄로 유지함

  • 프로그램 출력에서 문자열을 보고 코드에서 동일한 문자열을 검색할 수 있도록 하기 위함

• Rust, Javascript, Lisp는 함수 정의 앞에 키워드를 두어 검색이 용이함

  • C는 이러한 키워드가 없어 함수 이름만 검색할 수 있음
  • 일부 C 코딩 규칙은 정의를 두 줄로 나누어 검색을 용이하게 함

• greppability에 동의하지만, 경계를 넘어 이름을 동일하게 유지하는 것에는 반대함

  • 하나의 기호가 하나의 도메인에만 존재하는 것이 인지 부하를 줄임

• 코드 검색 가능성은 좋지만, 예제는 의도적으로 오류 가능성을 높임

  • 문자열 조건을 추가하면 입력과 출력 간의 불일치 가능성이 생김
  • 딕셔너리를 평탄화하면 오타가 발생할 가능성이 높아짐
  • 오타는 흔히 발생하며, 여러 코드베이스에 복사된 경우 해결이 어려움