Generic Intellisense의 새롭고 완전한 구현

Generic Intellisense의 새롭고 완전한 구현

---

SQL 및 C #에 대한 일반 Intellisense 지원 편집기를 작성하는 데 관심이 있습니다 (가능하면 등!). 재정의되거나 확장 된 WPF richTextBox 유형 컨트롤로 C #에서이 작업을 수행하고 싶습니다. 사용할 수있는 예제 프로젝트가 많이 있으며 기본 버전을 직접 구현했습니다 . 그러나 내가 본 (그리고 실제로 내 자신의) 예의 대부분은 기본 입니다.

몇 가지 코드 예제는 다음과 같습니다.

1. yetanotherchris의 DIY Intellisense

2. CodeTextBox-구문 강조 및 Intellisense가 포함 된 또 다른 RichTextBox 컨트롤 By Tamas Honfi

그러나 잘 작동하는 것으로 보이는 Mikael Håkansson의 Intellisense QueryCommander SQL 편집기 가있는 SQL 편집기의 훌륭한 예를 찾았습니다 . Microsoft는 명령 키워드의 XML 라이브러리를 사용해야하지만 내 질문은 다음과 같습니다. Microsoft는 Intellisense (당신이 입력 한대로 Intellisense)를 어떻게 (상세하게) 구현하며 동일한 표준을 직접 만드는 것이 얼마나 어려울까요?

---

편집 A : 1 년이 지난 지금은 주로 내 "즐거움"을 위해 기본 지능을 사용하여 자체 편집기 컨트롤을 개발했습니다. 제 자신의 개발에 도움이되었고 기본적으로 무료로 사용할 수있는 무료로 사용 가능한 .NET 프로젝트 목록을 다시 제공하겠다고 생각했습니다.

1. ICSharpCode (WinForms)

2. AvalonEdit (WPF)

3. ScintillaNET (WinForms)

4. Query Commander [예 : intellisense 구현] (WinForms)

---

편집 B : 질문을받은 지 15 개월이 지난 지금도 새롭고 향상된 편집자를 찾고 있습니다. 이거 좋네요 ...

1. RoslynPAD 는 멋지다!

---

C 편집 : 질문에서 2 년 이상, WPF를 사용하고 AvalonEdit에서 지원하는 다음 프로젝트를 찾았습니다.

1. NRefactory를 사용하는 AvalonEdit 용 CodeCompletion . 이 프로젝트는 정말 훌륭하고 NRefactory를 사용하여 intellisense를 완벽하게 구현했습니다.

2. ScriptCS ScriptCS를 사용하면 간단한 텍스트 편집기로 C #을 쉽게 작성하고 실행할 수 있습니다.

---

Microsoft는 사용자 유형 Intellisense를 어떻게 (자세히) 구현합니까?

나는 당신이 명명하고 싶은 어떤 수준의 세부 사항으로도 그것을 설명 할 수있다 . 그러나 나는 간단한 설명 이상의 시간이 없다. Roslyn에서 어떻게하는지 설명하겠습니다.

첫째, 우리는 편집을 효율적으로 표현할 수있는 데이터 구조를 사용하여 토큰 스트림의 불변 모델을 구축합니다. 편집은 정확히 많은 것이있을 것이기 때문입니다.

지속적인 재사용을 위해 효율적으로 만들기위한 핵심 통찰력 은 토큰 의 문자 길이 를 나타내지 만 편집 버퍼에서 문자 위치 를 나타내는 것입니다. 파일 끝에있는 토큰은 편집 할 때마다 위치가 변경되지만 토큰의 길이는 변경되지 않습니다. 매우 큰 파일을 효율적으로 처리하려면 모든 비용을 들여 총 렉싱 횟수를 최소화해야합니다.

매번 전체 파일을 다시 렉싱하지 않고 변경 불가능한 토큰 스트림을 구축하기 위해 삽입 및 삭제를 처리 할 수있는 변경 불가능한 모델이 있으면 동일한 작업 을 수행해야 하지만 문법 분석 을 수행해야합니다 . 이것은 실제로 상당히 어려운 문제 입니다. 파서 이론에 중점을 둔 컴퓨터 과학 학부 또는 대학원 학위를 아직 취득하지 않은 경우 취득하는 것이 좋습니다. 우리는 알고리즘의 특정 비트를 설계하기 위해 파서 이론에 대한 논문을 작성한 박사 학위를 가진 사람들의 도움을 얻었습니다.

그런 다음 C #을 분석 할 수있는 문법 분석기를 구축하십시오. 올바른 C #이 아니라 손상된 C # 을 분석 해야합니다 . IntelliSense는 프로그램이 비 컴파일 상태에있는 동안 작동해야합니다. 따라서 오류 복구 특성이 좋은 문법을 수정하는 것부터 시작하십시오.

좋습니다. 이제 편집 된 영역을 제외하고는 대부분의 시간을 다시 렉싱하거나 다시 구문 분석하지 않고도 문법 분석을 효율적으로 수행 할 수있는 구문 분석기가 있습니다. 즉, 키 입력 사이에 작업을 수행 할 수 있습니다. 물론 두 번의 키 입력 사이의 시간보다 분석이 더 오래 걸리는 경우 이러한 모든 분석을 수행하는 동안 UI 스레드 를 차단하지 않는 메커니즘을 마련해야합니다. C # 5의 새로운 "async / await"기능이 도움이 될 것입니다. (개인적 경험으로 말씀 드릴 수 있습니다. 과업과 취소 토큰의 확산에주의하십시오. 부주의하면 취소 된 작업이 수만 개가 대기중인 상태에 들어갈 수 있으며 이는 빠르지 않습니다 . )

이제 의미 분석기 를 구축하는 데 필요한 문법 분석을 얻었습니다 . IntelliSense 만 수행하기 때문에 특히 정교한 의미 분석기 일 필요는 없습니다. (우리의 시맨틱 분석기는 올바른 프로그램에서 코드를 생성하고 잘못된 프로그램에서 올바른 오류 분석을하는 데 적합한 분석을 수행해야합니다.) 그러나 물론, 다시 말해서 손상된 프로그램에 대해 좋은 의미 분석을 수행해야하므로 복잡성이 상당히 증가합니다.

내 조언은 "최상위"의미 분석기를 구축하는 것으로 시작하는 것입니다. 다시 한 번 편집에서 편집까지 선언 된 소스 코드 유형의 상태를 유지할 수있는 불변 모델을 사용합니다. 최상위 분석기는 유형 선언, 지시문, 네임 스페이스, 메서드 선언, 생성자, 소멸자 등 문이나식이 아닌 모든 것을 처리 합니다. 컴파일러가 메타 데이터를 생성 할 때 프로그램의 "모양"을 구성하는 것.

메타 데이터! 메타 데이터를 잊어 버렸습니다. 메타 데이터 리더가 필요합니다. 분명히 라이브러리의 형식을 참조하는 식에서 IntelliSense를 생성 할 수 있어야합니다. Reflection이 아닌 메타 데이터 리더로 CCI 라이브러리를 사용하는 것이 좋습니다. IntelliSense 만 수행하고 있기 때문에 분명히 메타 데이터 작성자가 필요하지 않습니다.

어쨌든 최상위 의미 분석기가 있으면 주어진 명령문의 표현식 유형을 분석하는 구문 및 표현식 의미 분석기를 작성할 수 있습니다. 이름 조회 및 과부하 해결 알고리즘에 특히주의하십시오 . 메서드 유형 유추는 특히 LINQ 쿼리 내부 에서 특히 까다로울 것 입니다.

이 모든 것을 갖추면 IntelliSense 엔진이 쉬워집니다. 현재 커서 위치에서 표현식 유형을 계산하고 적절하게 드롭 다운을 표시합니다.

동일한 표준으로 나만의 것을 만드는 것이 얼마나 어려울까요?

글쎄요, 우리는 10 명이라고 부르는 팀을 가지고 있습니다. 그리고 아마 처음부터 끝까지 모든 것을 끝내려면 5 년이 걸릴 것입니다. 그러나 우리는 IntelliSense 엔진보다 더 많은 것을 할 수 있습니다. 그것은 아마도 작업의 40 %에 불과할 것입니다. 아, 그리고 그 사람들의 절반은 VB에서 일하고 있습니다. 하지만 그 사람들은 이런 종류의 일을하는 데 평균 5 ~ 10 년의 경험을 가지고 있기 때문에 이전에 한 번도 해본 적이없는 것보다 훨씬 빠릅니다.

따라서 키 입력 사이의 시간에 대형 프로그램에 대해 허용 가능한 수준에 가까운 정확한 분석을 수행 할 수있는 C # 용 Roslyn 품질 IntelliSense 엔진을 빌드하려면 혼자 작업하는 데 약 10 ~ 20 년의 정규 작업이 필요하다고 가정 해 보겠습니다.

당연히 박사 학위를 먼저해야한다면 더 오래 걸립니다.

또는 Roslyn을 사용할 수 있습니다 .. 아마 몇 시간이 걸리 겠지만 스스로하는 재미는 없습니다. 그리고 재미 있습니다!

여기에서 미리보기 릴리스를 다운로드 할 수 있습니다.

http://www.microsoft.com/download/en/details.aspx?id=27746

---

이것은 Microsoft가 일반적으로 훌륭한 결과를 생성하는 영역입니다. Microsoft 개발자 도구는 정말 대단합니다. 그리고 개발자 도구를 판매하고 Windows를 판매하면 최고의 지능을 얻을 수 있다는 분명한 상업적 이점이 있으므로 Microsoft는 Eric이 그의 놀랍도록 상세한 답변에서 설명하는 리소스를 사용하는 것이 좋습니다. 그래도 몇 가지를 지적 할 가치가 있다고 생각합니다.

1. Your customers may not actually need all the features that Microsoft's implementation provides. The Microsoft solution might be incredibly over-engineered in terms of the features that you need to provide to your customers/users. Unless you're actually implementing a generic coding environment that is intended to be competitive with Visual Studio, it is likely that there are aspects of your intended use that either simplify the problem, or that allow you to make compromises on the solution that Microsoft feels they cannot make. Microsoft will likely spend resources decreasing response times that are already measured in hundreds of milliseconds. That may not be something you need to do. Microsoft is spending time on providing an API for others to use for code analysis. That's likely not part of your plan. Prioritize your features and decide what "good enough" looks like for you and your customers then estimate the cost of implementing that.

2. In addition to bearing the obvious costs of implementing requirements that you may not actually have, Microsoft also carries some costs that may not be obvious if you haven't worked in a team. There are huge communication costs associated with teams. It's actually incredibly easy to have five smart people take longer to produce a solution than it takes for a single smart person to produce the equivalent solution. There are aspects of Microsoft's hiring practices and organizational structure that make this scenario more likely. If you hire a bunch of smart people with egos and then empower all of them to make decisions, you too can get a 5% better solution for 500% of the cost. That 5% better solution might be profitable for Microsoft, but it could be deadly for a small company.

3. Going from a 1 person solution to a 5 person solution increases the costs, but that's just the intra-team development costs. Microsoft has separate teams that are devoted to (roughly) design, development, and testing even for a single feature. The project-related communication between peers across these boundaries has higher friction than within each of the disciplines. This not only increases communication costs between individuals, but it also results in larger team sizes. And more than that - since it's not a single team of 12 individuals, but is instead 3 teams of 5 individuals, there is 3x the upward communication cost. More costs that Microsoft has chosen to carry that may not translate to similar costs for other companies.

My point here is not to describe Microsoft as an inefficient company. My point is that Microsoft makes a ton of decisions about everything from hiring, to team organization, to design and implementation that start from assumptions about profitability and risk that simply do not apply to companies that are not Microsoft.

In terms of the intellisense thing, there are various ways of thinking about the problem. Microsoft is producing a very generic, reusable solution that doesn't just solve intellisense, but also targets code navigation, refactoring, and various other uses for code analysis. You don't need to do things the same way if your sole goal is to make it easy for developers to enter code without having to type much. Targeting that feature doesn't take years of effort and there are all sorts of creative things you can do if you're not just providing an API, but you actually control the UI too.

참고URL : https://stackoverflow.com/questions/9556026/a-new-and-full-implementation-of-generic-intellisense